Безопасность API: что проверить перед выпуском новой функции

Готов к релизу — значит ли это «безопасен к релизу»?

Почему проверка безопасности API стала критически важной задачей

Современное приложение — это преимущественно набор API-вызовов. По оценкам 2026 года, API обрабатывает более 80% всего веб-трафика [6]. Там, где трафик — там и атаки.

Между 2021 и 2025 годами атаки на API выросли в 7,8 раза. Средняя стоимость утечки данных, связанной с API, составила 4,88 миллиона долларов [6]. Это уже не статистика из отдалённого энтерпрайза: любая команда, выпускающая SaaS-продукт или мобильное приложение, работает с теми же рисками.

Среди практикующих специалистов прочно укоренился мем «это работает, значит, мы выкатываем». Проблема в том, что функционально работающий эндпоинт и безопасный к выпуску эндпоинт — это разные вещи. Новая фича может корректно обрабатывать запросы с правильным токеном и при этом возвращать чужие объекты, не ограничивать запросы по частоте, раскрывать структуру БД через сообщения об ошибках или хранить секреты прямо в коде.

Чек-лист ниже — не замена полноценной программе AppSec. Это набор конкретных проверок, которые следует пройти до того, как новая функция попадёт в production.

Откуда берётся контекст: OWASP API Security Top 10 (2023)

OWASP — некоммерческая организация, публикующая авторитетные стандарты в области безопасности приложений. В 2023 году вышла обновлённая редакция списка API Security Top 10, которую теперь используют аудиторы PCI-DSS, HIPAA, GDPR и DORA как практическую точку отсчёта [7].

Актуальный список на 2023–2026 год:

1. API1 — Broken Object Level Authorization (BOLA)
2. API2 — Broken Authentication
3. API3 — Broken Object Property Level Authorization (BOPLA)
4. API4 — Unrestricted Resource Consumption
5. API5 — Broken Function Level Authorization (BFLA)
6. API6 — Unrestricted Access to Sensitive Business Flows
7. API7 — Server-Side Request Forgery (SSRF)
8. API8 — Security Misconfiguration
9. API9 — Improper Inventory Management
10. API10 — Unsafe Consumption of APIs

В редакции 2023 года произошли важные изменения. «Excessive Data Exposure» и «Mass Assignment» объединили в BOPLA — потому что корневая причина у них одна: API отдаёт или принимает больше полей, чем должен. SSRF получил отдельную строку из-за роста атак через webhook'и и metadata-эндпоинты облачных провайдеров. Unsafe Consumption of APIs (API10) заменил Insufficient Logging — потому что доверие к сторонним API без проверки ответов стало самостоятельным вектором атак [8].

Блок 1. Аутентификация и авторизация

Что проверять

Это самый распространённый источник инцидентов. Важно сразу зафиксировать: аутентификация (кто вы?) и авторизация (что вам разрешено?) — разные уровни контроля, и почти все реальные взломы эксплуатируют именно авторизацию [3].

Перед релизом проверьте следующее.

Аутентификация:

• Используется ли OAuth 2.1 или OpenID Connect вместо самописных схем? Для мобильных приложений и SPA — OAuth 2.1 с PKCE обязателен [6].
• Устаревшие флоу (Implicit, Password Grant) исключены?
• Access-токены имеют короткое время жизни (5–15 минут) и подписаны RS256 или ES256?
• Валидируются ли claims (iss, aud, exp) при каждом запросе?
• Refresh-токены реализованы через rotation: каждый использован один раз, после чего выпускается новый?
• JWT не содержит секретов, паролей или PII в payload — JWT base64-encoded, но не зашифрован [9].

Авторизация на уровне объектов (BOLA, API1):

• Для каждого эндпоинта, принимающего ID объекта, проверяется: принадлежит ли этот объект текущему пользователю?
• Сравнение ID из токена с ID в запросе — это необходимое, но не достаточное условие. BOLA-уязвимость присутствует именно там, где пользователь по дизайну имеет доступ к эндпоинту, но не к конкретному объекту [10].
• Проверки выполняются на каждый запрос, не только при первом обращении.

Авторизация на уровне функций (BFLA, API5):

• Административные и привилегированные эндпоинты защищены отдельно от пользовательских?
• Доступ к чувствительным операциям (экспорт данных, управление пользователями, изменение конфигурации) требует явно заданной роли?

Принцип минимальных привилегий:

• Сервисные аккаунты и API-ключи имеют только те права, которые нужны для конкретной задачи. В 2024 году утечка в BeyondTrust произошла из-за единственного API-ключа с избыточными правами, что привело к компрометации данных из 17 SaaS-провайдеров [11].
• Для service-to-service взаимодействий рекомендуется mTLS или подписанные запросы.

Блок 2. Валидация входных данных

Почему это критично

Инъекции (SQL, NoSQL, command, SSRF) по-прежнему актуальны, даже если ваш фреймворк умеет параметризованные запросы. Новая функциональность часто добавляет новые поля ввода, которые не проходят через существующие валидаторы.

Чек-лист перед релизом:

• Все входные данные валидируются на стороне сервера — не только на клиенте.
• Строки очищаются от HTML, SQL и shell-метасимволов перед использованием в запросах, командах или выводе [4].
• Загружаемые файлы проверяются по MIME-type, расширению и содержимому (не только по заголовку). Загрузки сканируются на вредоносное ПО.
• Ограничен максимальный размер тела запроса. Неограниченный размер payload — вектор DoS и memory exhaustion [4].
• Content-Type заголовок валидируется: API не обрабатывает неожиданные форматы данных.
• Нет прямой передачи user input в динамические запросы — только параметризованные запросы или ORM.

Отдельный риск для новых фич: если функция принимает структурированные объекты (JSON, XML), убедитесь, что API не принимает лишние поля через mass assignment. Это BOPLA (API3): API принимает isAdmin: true или role: "superuser" в теле запроса и применяет эти значения без проверки.

Блок 3. Rate Limiting и защита от злоупотреблений

Почему это не опция

Без rate limiting API открыт для брутфорса, credential stuffing, скрейпинга данных и исчерпания ресурсов. Это касается и ваших новых эндпоинтов [12].

Перед релизом проверьте:

• Rate limiting применён per-client: по API-ключу, user ID или IP-адресу. Глобальные лимиты легко обходятся [4].
• Эндпоинты аутентификации (login, password reset, OTP) имеют агрессивные ограничения и account lockout.
• При превышении лимита возвращается HTTP 429 Too Many Requests с заголовком Retry-After.
• Лимиты настроены на основе реальных данных о потреблении — желательно из staging или ограниченного production за 2–4 недели [12].
• Новые эндпоинты, связанные с платными операциями, генерацией контента или дорогостоящими вычислениями, защищены отдельно (API6 — Unrestricted Access to Sensitive Business Flows).

Если новая функция вызывает внешние API или тяжёлые операции (ML-inference, отчёты, экспорты) — лимиты должны быть строже, а не мягче.

Блок 4. Транспортная безопасность и заголовки

Базовые требования

• Только HTTPS (TLS 1.2+). HTTP-запросы редиректятся на HTTPS или блокируются.
• Security-заголовки настроены. Минимальный обязательный набор:

- Strict-Transport-Security (HSTS) - X-Content-Type-Options: nosniff - X-Frame-Options: DENY или SAMEORIGIN - Content-Security-Policy - X-Powered-By — скрыт или удалён

• В production-окружении отключены verbose error-сообщения, stack traces и debug-режимы [13].

CORS: один из самых недооценённых векторов

CORS-мисконфигурации регулярно встречаются в bug bounty и реальных инцидентах. Уязвимость возникает, когда сервер некорректно валидирует Origin-заголовок [5, 14].

Перед релизом проверьте:

• Access-Control-Allow-Origin: * запрещён для эндпоинтов, работающих с сессиями или чувствительными данными.
• Не используется комбинация Access-Control-Allow-Origin: * + Access-Control-Allow-Credentials: true — эта комбинация позволяет любому сайту выполнять аутентифицированные запросы от имени пользователя [15].
• Origin-значения из запроса не отражаются в ответе без явной проверки по allowlist (именно такая уязвимость была обнаружена в Strapi) [14].
• Разрешены только необходимые HTTP-методы и заголовки.
• Preflight-запросы (OPTIONS) обрабатываются корректно.

Блок 5. Управление секретами и конфигурацией

Где чаще всего «прячутся» проблемы

Утечки секретов в коде — один из самых распространённых источников инцидентов. Новая функция часто означает новые API-ключи, токены или строки подключения, которые разработчик «временно» кладёт прямо в код.

Проверочный список перед релизом:

• Все секреты (API-ключи, токены, пароли БД, signing-secrets) хранятся в vault или secret manager, не в коде и не в .env-файлах, попадающих в репозиторий.
• Каждый секрет разделён по окружениям: production-ключи не используются в staging и наоборот.
• Ротация ключей задокументирована и реализуема.
• Переменные окружения, конфиги и migration-файлы прошли отдельный review.
• Git-история нового кода проверена на случайные коммиты с секретами (git-secrets, TruffleHog, GitLeaks).
• Debug-эндпоинты (/debug, /test, /admin/console) закрыты или отсутствуют в production [13].
• Конфигурация окружения соответствует production: выключены verbose-логи приложения, режимы отладки, тестовые учётные данные.

Блок 6. Минимизация данных в ответах

BOPLA и overexposure

API3:2023 (Broken Object Property Level Authorization) — это когда API возвращает или принимает больше полей, чем должен. Типичный пример: эндпоинт для получения профиля пользователя возвращает password_hash, internal_role, stripe_customer_id и другие поля, которые клиенту не нужны.

Перед релизом проверьте:

• Response-объекты содержат только поля, необходимые конкретному клиенту (серверный allow-list, а не block-list).
• Поля с чувствительными данными (хэши паролей, внутренние идентификаторы, финансовые данные) явно исключены из ответов.
• Разные роли получают разные наборы полей — это проверено тестами, а не только документацией.
• Pagination реализован и ограничивает максимальный размер страницы — нет эндпоинтов, возвращающих весь датасет без ограничений.

Блок 7. Логирование и мониторинг

Почему логи — это не только про debugging

Согласно OWASP и данным индустрии, многие организации узнают об API-взломах только спустя месяцы — именно из-за недостаточного мониторинга [16]. Логи без структуры и алертов без мониторинга практически бесполезны при реагировании на инцидент.

Перед релизом новой фичи проверьте:

• Логируются ли попытки аутентификации (успешные и неуспешные)?
• Логируются ли критические операции: смена прав доступа, массовые операции с данными, административные действия?
• В логах нет PII, токенов, паролей или ключей — только метаданные событий.
• Структурированное логирование (JSON) настроено для удобного поиска и алертинга [17].
• Аномалии (спайки трафика, массовые 401/403/429) будут замечены мониторингом до того, как превратятся в инцидент.
• Логи защищены от изменения и недоступны для перезаписи атакующим.

Для production-систем с чёткими compliance-требованиями (PCI-DSS, HIPAA, GDPR) audit trail — не рекомендация, а обязательное требование.

Блок 8. Инвентаризация и теневые API

Проблема, которую называют «тихим убийцей»

API9:2023 (Improper Inventory Management) регулярно недооценивается командами. Речь о ситуации, когда в production живут устаревшие, недокументированные или «временные» эндпоинты, которые не проходят security-проверки и не мониторируются [18].

Перед выпуском новой функции:

• Все новые эндпоинты задокументированы (OpenAPI/Swagger).
• Устаревшие версии API (v1, если уже есть v2) — запланированы к выводу или уже выведены из эксплуатации.
• Нет «временных» debug-маршрутов, оставленных для тестирования.
• Shadow API (эндпоинты, обнаруженные через прокси-перехват, но не входящие в документацию) выявлены и закрыты.

Блок 9. Безопасность зависимостей и сторонних API

Риск, который «приезжает» вместе с новой функцией

Если новая фича добавляет зависимость или вызывает сторонний API — это самостоятельный вектор атак.

API10:2023 (Unsafe Consumption of APIs) описывает ситуацию, когда сервис доверяет ответам стороннего API без валидации. Компрометация поставщика может автоматически стать компрометацией вашего сервиса.

Что проверить:

• Новые зависимости проверены через SCA (Software Composition Analysis): нет известных CVE в основных или транзитивных пакетах.
• Lock-файлы актуальны и зафиксированы.
• Ответы от сторонних API валидируются по схеме, а не принимаются как есть.
• Таймауты и обработка ошибок при обращении к внешним сервисам настроены: внешний сбой не должен каскадно роняет вашу систему.
• SSRF (API7): новая фича не принимает URL от пользователя и не делает HTTP-запросы по пользовательским адресам без явной проверки по allowlist.

Практический decision framework: что блокирует релиз, а что идёт в backlog

Не все проблемы одинаковы. Вот упрощённая схема приоритизации.

Блокирует релиз (Critical/High):

• Отсутствие аутентификации на новом эндпоинте.
• BOLA: проверки на уровне объекта не реализованы.
• Секреты в коде или конфигурации.
• CORS: wildcard + credentials на защищённых эндпоинтах.
• SQL/command injection.
• Отсутствие TLS.
• SSRF: приём произвольных URL от пользователя.

Требует исправления до или сразу после релиза (Medium):

• Rate limiting отсутствует на публичных или аутентификационных эндпоинтах.
• Избыточные данные в ответах (BOPLA).
• Debug-режим или verbose errors в production.
• Недостаточное логирование критических операций.

Backlog (Low/Informational):

• Недостаточно строгий CSP.
• Отсутствие HSTS preload.
• Документация не соответствует реализации.
• Устаревшая, но не эксплуатируемая версия зависимости.

Типичные ошибки команд и как их избежать

Ошибка 1. «Security review — это отдельный этап перед релизом»

Проблема: к тому моменту переделывать архитектурные решения уже дорого и поздно.

Практика: threat modeling на этапе дизайна фичи — задать три вопроса: что происходит, если этот эндпоинт вызывает неавторизованный пользователь? какие объекты можно перебрать? что будет, если передать сюда произвольные данные? [19]

Ошибка 2. «AI написал, значит, всё правильно»

Данные Cloud Security Alliance (2025) показывают, что 62% кода, сгенерированного AI-инструментами, содержит архитектурные дефекты или известные уязвимости из-за отсутствия threat model и policy context [20]. AI-ассистент хорошо пишет бизнес-логику, но не знает вашего security-контекста: какие данные чувствительны, как устроена авторизационная модель, где проходят границы доверия.

Ошибка 3. «PR прочитали, значит, всё проверили»

Проверка кода в рамках code review и security-проверка — разные вещи. Диф дочитывают не до конца. Конфиги, migration-файлы и CI/CD-скрипты проверяют хуже всего.

Ошибка 4. «Rate limiting настроен глобально — значит, мы защищены»

Глобальные лимиты легко обойти: атакующий распределяет запросы по разным IP. Лимиты должны быть per-client (по user ID или API-ключу) и особенно жёсткими для аутентификационных эндпоинтов.

Ошибка 5. «Проверили один раз при запуске — и достаточно»

Security posture деградирует с каждым изменением. Новая зависимость может принести CVE, изменение конфигурации — открыть debug-эндпоинт, рефакторинг — сломать авторизационную проверку. Непрерывный мониторинг и периодические security review обязательны.

Как встроить всё это в процесс, не добавляя бюрократии

Идея «безопасность как отдельный чеклист перед релизом» работает хуже, чем «безопасность как часть обычного процесса». Практические шаги:

1. Threat modeling на этапе planning: 15–20 минут на три вопроса для каждой новой фичи.
2. Security criteria в Definition of Done: аутентификация, авторизация, валидация входных данных, rate limiting — явные требования к задаче, а не пожелание.
3. Автоматизированные проверки в CI: SAST, SCA, secrets scanning, проверка security-заголовков на каждый PR [21].
4. Security gate перед merge: явное подтверждение, что новый эндпоинт прошёл минимальный список проверок.
5. Структурированный code review: отдельный чеклист для security-аспектов при ревью нового кода [3].

Принцип тот же, что в авиации: pre-flight checklist существует не потому, что пилоты забывчивы, а потому что предсказуемые риски требуют предсказуемого контроля. Пропустить одно поле в документе — ошибка; пропустить проверку авторизации перед выпуском — инцидент [11].

Команды, которые используют AI-инструменты для ускорения разработки, сталкиваются с дополнительным вызовом: скорость генерации кода выросла, но контроль изменений не успел за ней. В этом контексте слой проверки непосредственно перед merge и релизом — не лишняя бюрократия, а необходимый ответ на увеличившийся поток изменений. Именно эту роль играет HighVibe: анализ конкретного изменения в коде, конфигурации и зависимостях с коротким и понятным сигналом — можно ли безопасно принять это изменение прямо сейчас.

Итог: что делать прямо сейчас

Если у вас нет формального security-процесса, начните с малого:

1. Возьмите OWASP API Security Top 10 (2023) — это бесплатный, авторитетный и практичный список.
2. Для каждой новой фичи пройдите три вопроса threat modeling (кто может это вызвать, что они получат, что случится при злоупотреблении).
3. Добавьте в Definition of Done явные security criteria для новых эндпоинтов.
4. Настройте хотя бы минимальный secrets scanning и SCA в CI — это займёт несколько часов и закроет целый класс распространённых инцидентов.
5. Проверьте CORS и rate limiting на всех новых эндпоинтах до выкатки.

Безопасность API — это не финальная проверка, а непрерывный процесс. Каждый коммит может принести уязвимость, каждая новая зависимость — CVE, каждая конфигурация — точку входа. Чем раньше контроль встроен в процесс, тем дешевле исправление и тем ниже риск для пользователей и бизнеса.

Источники

[1] OWASP — "API1:2023 Broken Object Level Authorization" — https://owasp.org/API-Security/editions/2023/en/0xa1-broken-object-level-authorization/

[2] Wiz — "API Security Checklist 2026" — https://www.wiz.io/academy/api-security/api-security-checklist

[3] Levo.ai — "REST API Security Best Practices (2026)" — https://www.levo.ai/resources/blogs/rest-api-security-best-practices

[4] AquilaX — "API Security Checklist 2026" — https://aquilax.ai/blog/api-security-checklist

[5] Intigriti — "CORS Misconfigurations: Advanced Exploitation Guide" — https://www.intigriti.com/researchers/blog/hacking-tools/exploiting-cors-misconfiguration-vulnerabilities

[6] daily.dev — "Dev Guide to API Security: OAuth 2.1, JWT Best Practices, and Common Vulnerabilities" — https://daily.dev/blog/dev-guide-api-security-oauth-2-1-jwt-vulnerabilities

[7] AccuKnox — "OWASP API Security Testing Checklist 2026" — https://accuknox.com/blog/owasp-api-security-top-10-the-complete-testing-checklist-2026

[8] Wiz — "OWASP API Security Top 10 Risks and How to Mitigate Them" — https://www.wiz.io/academy/api-security/owasp-api-security

[9] Browserless — "API Security: Best Practices and OWASP Top 10" — https://www.browserless.io/blog/api-security

[10] OWASP — "API1:2023 BOLA (полное описание)" — https://owasp.org/API-Security/editions/2023/en/0xa1-broken-object-level-authorization/

[11] Apono — "The Required API Security Checklist" — https://www.apono.io/blog/the-required-api-security-checklist-xls-download/

[12] TechMarcos — "API Rate Limiting & Security Guide for Developers" — https://www.techmarcos.com/api-rate-limiting-security-implementation-guide/

[13] Snyk Learn — "API Security Misconfigurations" — https://learn.snyk.io/lesson/security-misconfiguration-api/

[14] GitHub Advisory — "CORS Misconfiguration Leads to Sensitive Data Exposure (Strapi)" — https://github.com/strapi/strapi/security/advisories/GHSA-9329-mxxw-qwf8

[15] Outpost24 — "CORS vulnerabilities: Weaponizing permissive CORS configurations" — https://outpost24.com/blog/exploiting-permissive-cors-configurations/

[16] Aikido — "API Security: The Complete 2025 Guide" — https://www.aikido.dev/blog/api-security-guide

[17] AppSentinels — "API Audit Checklist 2025" — https://appsentinels.ai/blog/blog-api-audit-checklist-a-comprehensive-guide-for-security-leaders/

[18] Practical DevSecOps — "OWASP API Security Top 10: 2023 Update Explained" — https://www.practical-devsecops.com/owasp-api-security-top-10/

[19] SecureFlag — "Integrating Threat Modeling into the SDLC" — https://blog.secureflag.com/2025/08/15/integrating-threat-modeling-into-sdlc/

[20] OX Security — "Secure SDLC in the Age of AI: From Static Checks to Active Risk Control" — https://www.ox.security/blog/secure-sdlc/

[21] Avatao — "Secure SDLC (SSDLC) & Shift-Left" — https://avatao.com/secure-software-development-life-cycle-ssdlc-and-the-shift-left-approach/