Безопасность API: базовый чек-лист для продуктовой команды

Что проверить до того, как уязвимость станет инцидентом

Почему API — это больше не «техническая» тема

Несколько лет назад разговор о безопасности API был привилегией команд безопасности. Сегодня это вопрос выживания продукта.

По данным Akamai, через API проходит около 83% всего веб-трафика [3]. Каждый раз, когда мобильное приложение отдаёт данные пользователю, партнёрский сервис обращается к вашей платформе или внутренний микросервис делает запрос — за этим стоит API. И каждая из этих точек входа может быть атакована.

Статистика неутешительна. За первое полугодие 2025 года зафиксировано свыше 40 000 API-инцидентов — в среднем более 220 в день [3]. Поведенческие атаки (несанкционированные рабочие процессы) выросли с 30% в 2024 году до 61% всех API-атак в 2025-м [3]. Почти каждая вторая из этих атак эксплуатирует нарушение аутентификации — по анализу 60 реальных инцидентов, она стала причиной 52% взломов [3].

Это меняет требования к продуктовым командам. Безопасность API больше не является задачей, которую можно делегировать «куда-то в security» и забыть. Она встраивается в design review, в PR, в релизный процесс.

В России тема также актуальна: Банк России в конце 2024 года опубликовал стандарты безопасности открытых API, разработанные АФТ совместно с ИнфоТеКС [4]. Крупные игроки — Сбер, Ozon, другие — публично говорят о том, что IDOR и нарушения авторизации остаются одними из самых частых проблем при аудите API [5]. Глобальные best practices при этом применимы повсеместно: угрозы не имеют географических границ.

Что такое OWASP API Security Top 10 и зачем он нужен

Прежде чем перейти к чек-листу, важно понять точку отсчёта.

OWASP API Security Top 10 — это список наиболее критичных категорий уязвимостей API, который ведёт Open Web Application Security Project. Актуальная редакция вышла в 2023 году и отразила реальные сдвиги в ландшафте угроз: рост облачных атак, злоупотребление бизнес-логикой, появление SSRF как отдельной категории [6].

Важное уточнение, которое часто упускают: OWASP API Top 10 — это не то же самое, что OWASP Web Application Top 10. Веб-список фокусируется на браузерных уязвимостях (XSS, небезопасная десериализация). API-список ориентирован на сбои логики авторизации, злоупотребление потоками и поведенческие уязвимости, которые правилами сигнатурного сканирования не поймать [7].

Десять категорий 2023 года:

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

Все семь зон чек-листа ниже привязаны к этим категориям. Это не абстрактные рекомендации — это конкретные риски, которые регулярно эксплуатируются в реальных атаках.

Зона 1. Инвентаризация API: что вы вообще защищаете

Невозможно защитить то, о чём не знаешь. Звучит банально, но именно здесь большинство команд спотыкаются на старте.

Поддержание актуального инвентаря API называет второй по сложности задачей 37% организаций, которые работают над безопасностью API [8]. Первое место — сама распространённость и sprawl API (48%).

Две главные категории «невидимых» API:

Shadow APIs — это эндпоинты, развёрнутые быстро и не прошедшие через официальный процесс согласования или аудит безопасности [9]. Часто это MVP-интеграции, быстро сделанные внутренние инструменты, временные прототипы, которые внезапно оказались в production. Они существуют в слепой зоне — security-команда о них не знает, мониторинг их не охватывает.

Zombie APIs — это депрекейтные версии API, которые логически «выключены» (фронтенд их больше не вызывает), но продолжают быть доступны на бекенде [9]. Они не обновляются, не мониторятся, не патчатся. В 2025 году произошла показательная кампания: злоумышленники эксплуатировали депрекейтный API Stripe для кражи платёжных данных с нескольких e-commerce сайтов, оставаясь незамеченными длительное время [10].

Выход один: систематическая инвентаризация. Это означает не только список известных API, но и автоматическое обнаружение неизвестных через анализ трафика, статический анализ кода, сканирование инфраструктуры.

Практический чек-лист для этой зоны:

• Ведётся ли единый реестр всех API (публичных, внутренних, партнёрских)?
• Включены ли в реестр сторонние API, которые потребляет ваш продукт?
• Есть ли процесс обнаружения shadow и zombie API (сканирование трафика, периодический аудит)?
• Определён ли процесс вывода из эксплуатации (sunset) для старых версий?
• Есть ли владелец каждого API в реестре?

Зона 2. Аутентификация: кто вы такой

Сломанная аутентификация (API2:2023) — вторая по частоте категория в OWASP и первая по реальному ущербу в 2025 году: по данным Wallarm, она стала причиной 52% взломов из 60 проанализированных инцидентов [3].

Что входит в понятие «сломанная аутентификация»: слабые токены, долгоживущие сессии, отсутствие MFA на критичных эндпоинтах, уязвимые механизмы сброса паролей, credential stuffing без защиты. Иными словами — всё, что позволяет злоумышленнику выдать себя за легитимного пользователя или систему.

Несколько реальных сценариев. В 2025 году исследователи обнаружили, что в API мобильного приложения Volkswagen MyVW отсутствовал rate limiting на эндпоинте верификации OTP. Брутфорс-скрипт взламывал одноразовый пароль — и после этого API возвращал учётные данные внутренних систем в открытом виде, а также персональные данные владельца автомобиля по VIN [1]. Две отдельные уязвимости аутентификации, обе — базовые.

Современный стандарт аутентификации для API: OAuth 2.0 с короткоживущими токенами доступа и механизмом обновления (refresh workflow), OpenID Connect для идентификации пользователей, mTLS (mutual TLS) для межсервисного взаимодействия [11]. Для финансово-критичных API рекомендован профиль FAPI (Financial-grade API) и RFC 8705 для mTLS-аутентификации клиента [12].

Чего не делать: кастомные схемы аутентификации, Basic Auth без HTTPS, вечные API-ключи без ротации, отсутствие MFA на административных эндпоинтах.

Практический чек-лист:

• Все эндпоинты используют стандартные протоколы (OAuth 2.0, JWT, OpenID Connect, mTLS)?
• Токены короткоживущие? Есть ли механизм отзыва?
• API-ключи и токены хранятся в секретнице (AWS KMS, HashiCorp Vault) — не в коде и не в репозитории?
• На административных и чувствительных эндпоинтах включена MFA?
• Настроены ли lockout-политики и rate limiting на эндпоинтах аутентификации?
• Защищены ли эндпоинты сброса пароля и одноразовых ссылок отдельно?

Зона 3. Авторизация: что вам разрешено делать

Нарушения авторизации занимают первое место в OWASP API Top 10 с 2019 года и не сдают позиций: BOLA (Broken Object Level Authorization) присутствует примерно в 40% всех API-атак [13].

Разница между аутентификацией и авторизацией критична: аутентификация проверяет «кто вы», авторизация — «что вам разрешено». Системы часто хорошо справляются с первым и плохо — со вторым.

Классическая атака BOLA: пользователь авторизован и запрашивает GET /api/orders/12345. Если изменить ID на 12345+1 — открываются данные другого пользователя. Никакой сложной эксплуатации. Просто отсутствие проверки на сервере: принадлежит ли этот объект запрашивающему [6].

Dell в 2024 году потерял данные 49 миллионов клиентов именно так: атакующий перебирал сервисные теги в API партнёрского портала, получая полные профили клиентов — без rate limiting и без проверки авторизации на объектном уровне [3].

Дополнительная категория — Broken Object Property Level Authorization (API3:2023) — описывает случаи, когда API возвращает больше полей, чем должен (mass assignment, excessive data exposure). Пользователь делает запрос на получение профиля и получает в ответе поля internal_role, api_secret, admin_flag — потому что сериализатор отдаёт «всё подряд».

Правильный подход: принцип наименьших привилегий на уровне каждого запроса. Проверка прав происходит на сервере для каждого объекта при каждом вызове. Нельзя полагаться на ID, переданный клиентом — нужно сверять с сессией [16]. RBAC/ABAC с явным указанием разрешённых полей в ответе.

Практический чек-лист:

• Авторизация проверяется на сервере для каждого объекта при каждом запросе (не только на уровне сессии)?
• API не принимает ID объекта от клиента как доверенный источник?
• API не возвращает лишних полей (фильтрация ответа, explicit allowlist)?
• Применены RBAC или ABAC с принципом наименьших привилегий?
• Функциональная авторизация (кто может вызвать какой эндпоинт) отделена от объектной?

Зона 4. Секреты и защита данных в транзите

Один из самых предотвращаемых, но при этом массовых классов проблем — секреты в коде.

В 2024 году GitHub обнаружил в репозиториях более 39 миллионов утечек секретов: API-ключей, токенов, SSH-ключей, учётных данных — рост на 67% по сравнению с предыдущим годом [14]. Компания прямо называет это «одной из самых распространённых и одновременно предотвращаемых причин инцидентов безопасности» [15].

Секреты попадают в репозитории по нескольким типичным путям: разработчик хардкодит ключ «временно» и забывает удалить; env-файл с реальными ключами случайно коммитится; при публикации приватного репозитория — тот, что раньше был «безопасным», становится открытым; в истории коммитов остаются следы, даже если файл удалён [14].

Отдельный риск — скомпрометированный секрет, который остаётся живым. Удаление файла из репозитория не отзывает ключ. До тех пор пока учётные данные не ротированы, они представляют угрозу, независимо от того, «видны» ли они сейчас [16].

Для данных в транзите стандарт однозначен: TLS 1.2 как минимум, TLS 1.3 как предпочтительный вариант. По данным F5, почти треть клиентских API в 2024 году всё ещё работала без базового шифрования [17]. Это не академическая угроза: незашифрованный API-трафик перехватывается на уровне сети, сетевого оборудования, прокси, CDN.

Практический чек-лист:

• Все API работают только через HTTPS/TLS 1.2+?
• Секреты хранятся в выделенном хранилище (Vault, AWS Secrets Manager, Azure Key Vault)?
• Настроено автоматическое сканирование репозиториев на предмет утечки секретов (GitHub Secret Scanning, GitGuardian, аналоги)?
• Настроена ротация API-ключей и токенов?
• Ключи с истёкшим сроком действия отзываются автоматически?
• API-ключи не передаются в URL (query string) — только в заголовках?

Зона 5. Rate limiting и защита от злоупотреблений

Отсутствие rate limiting — не просто неудобство. Это прямой путь к DoS, брутфорсу, scraping и злоупотреблению бизнес-логикой.

История с Volkswagen MyVW — показательна: брутфорс OTP стал возможен только потому, что на эндпоинте верификации не было ограничений на количество попыток [1]. История с Dell — аналогична: 49 миллионов записей были вытащены перебором сервисных тегов через API, который не имел ни rate limiting, ни поведенческого мониторинга [3].

OWASP API4:2023 называет неограниченное потребление ресурсов отдельной категорией риска. Это не только классический «слишком много запросов», но и:

• запросы, возвращающие аномально большие объёмы данных;
• пакетные операции без ограничения размера;
• длительные вычислительные задачи, запускаемые через API без квот;
• злоупотребление сценариями бизнес-логики (mass signup, coupon abuse, loyalty point gaming) — API6:2023.

Rate limiting должен быть дифференцированным: по IP, по пользователю, по API-ключу, по эндпоинту. Жёсткий глобальный лимит не заменяет гранулярный контроль. Современные API-шлюзы (Kong, Apigee, AWS API Gateway, Envoy) поддерживают это нативно [18].

Практический чек-лист:

• Rate limiting настроен на всех публичных эндпоинтах?
• Эндпоинты аутентификации (логин, сброс пароля, OTP) имеют отдельные, более жёсткие лимиты?
• Есть ли ограничения на размер запроса и ответа?
• Ограничены ли пакетные операции (batch endpoints)?
• Настроены ли блокировки по IP при превышении порогов?
• Защищены ли чувствительные бизнес-потоки (регистрация, оплата, бонусы) от автоматизированного злоупотребления?

Зона 6. Конфигурация и заголовки безопасности

Security Misconfiguration занимает восьмую строчку в OWASP, но в реальности это один из самых частых источников инцидентов. Проблема не в отсутствии знаний — а в том, что «дефолтные» настройки часто небезопасны, а времени на конфигурирование не хватает.

CORS — один из ключевых примеров. Cross-Origin Resource Sharing контролирует, каким доменам разрешено обращаться к вашему API из браузера. Настройка Access-Control-Allow-Origin: * — открытый CORS — означает, что любой домен может делать кросс-доменные запросы к вашему API. Для публичных, полностью открытых данных это может быть приемлемо. Для эндпоинтов с сессионными данными или чувствительной информацией — это уязвимость [19].

Частые ошибки при настройке CORS: динамическая генерация заголовка Access-Control-Allow-Origin из пользовательского запроса без валидации; использование регулярного выражения с ошибкой (например, *.example.com матчит evilexample.com); whitelist с null origin для поддержки локальной разработки, который оставляют в production [20].

Другие распространённые мисконфигурации:

• Debug mode в production: подробные стек-трейсы, раскрывающие внутреннюю архитектуру.
• Открытые Swagger/OpenAPI-документы без аутентификации на production-среде.
• Отсутствие security-заголовков: Strict-Transport-Security, X-Content-Type-Options, X-Frame-Options, Content-Security-Policy.
• Дефолтные пароли на API-шлюзах и инструментах администрирования.
• Избыточная информация в сообщениях об ошибках (имена таблиц, внутренние ID, пути к файлам).

Практический чек-лист:

• CORS настроен через строгий whitelist доменов (не * для чувствительных эндпоинтов)?
• Debug-режим, подробные стек-трейсы и внутренняя диагностика отключены в production?
• Swagger/OpenAPI документация закрыта аутентификацией или недоступна в production?
• Security-заголовки выставлены для всех ответов?
• Сообщения об ошибках не раскрывают внутреннюю структуру (имена таблиц, пути, фреймворки)?
• Все неиспользуемые методы HTTP отключены на эндпоинтах?
• Конфигурация API-шлюза проходит регулярный аудит?

Зона 7. Логирование, мониторинг и реакция на инциденты

Недостаточное логирование и мониторинг — это не отдельная уязвимость, но мультиплицирующий фактор: именно они превращают атаку, которую можно было остановить за часы, в инцидент продолжительностью в недели.

По данным IBM Ponemon 2025, средний жизненный цикл утечки данных длительностью менее 200 дней обходится в $3,87 млн; свыше 200 дней — значительно дороже [2]. Главный фактор сокращения времени обнаружения — собственные системы мониторинга организации с применением AI и автоматизации.

Многие API-инциденты остаются незамеченными неделями и месяцами именно из-за отсутствия логирования аномальной активности [21]. Без логов нельзя обнаружить, что кто-то систематически перебирает ID объектов. Нельзя заметить аномальный рост числа ошибок аутентификации. Нельзя восстановить картину атаки post factum для разбора.

Что должен содержать API-лог минимально: timestamp, метод и эндпоинт, IP-адрес и User-Agent источника, идентификатор пользователя или токена (без самого токена), HTTP-статус ответа, время обработки. Чего не должно быть в логах: паролей, токенов, чувствительных полей тела запроса (номера карт, SSN, персональные данные) [22].

Эффективный мониторинг отслеживает отклонения от нормы: всплески трафика к одному эндпоинту, высокое число ошибок 401/403, доступ к эндпоинтам в нетипичное время, обращения к депрекейтным API-версиям, аномальные объёмы данных в ответах. Всё это — сигналы, которые могут указывать на разведку или активную атаку [22].

Практический чек-лист:

• Все запросы к API логируются (без чувствительных данных в теле)?
• Логи централизованы и доступны для анализа (SIEM, ELK, CloudWatch, аналоги)?
• Настроены алерты на аномальное поведение (превышение лимитов, паттерны ошибок, нетипичный доступ)?
• Определены SLA на реакцию для разных классов инцидентов?
• Логи доступны для retro-анализа минимум 90 дней?
• Мониторинг охватывает все среды, включая staging (где часто забывают)?

Типичные ошибки продуктовых команд

Знание OWASP-списка не гарантирует безопасности. Вот что реально идёт не так.

Авторизация проверяется только на уровне сессии. Команда включает middleware, который проверяет «залогинен ли пользователь», и считает задачу решённой. Но доступ к конкретным объектам не проверяется — и появляется BOLA.

«Работает» принимается за «безопасно». Pull request с новым API-эндпоинтом проходит ревью кода, функциональное тестирование, интеграционные тесты — и никто не спрашивает: а правильно ли настроена авторизация на объектном уровне? Есть ли rate limiting? Что возвращается в ответе лишнего?

Секреты остаются в истории коммитов. Разработчик добавляет ключ, замечает ошибку, удаляет файл и делает новый коммит. Но в Git-истории ключ остаётся. До тех пор пока он не отозван и не ротирован — угроза реальна [14].

Конфигурация «как в dev» уходит в production. CORS открыт «для тестов». Swagger доступен. Debug-логи включены. В суете релиза это не замечают.

Мониторинг есть, но алертов нет. Логи пишутся, но никто не смотрит на аномалии систематически. Инцидент обнаруживается не внутренними системами, а третьей стороной — или уже после того, как ущерб нанесён.

Zombie API никто не выключает. Старая версия API формально заменена новой. Но старая доступна — и в ней нет патчей безопасности, которые вышли за последний год.

Как это соотносится с AI-кодингом

Отдельная тема, которую нельзя обойти в 2025 году: API-эндпоинты, написанные или изменённые с помощью AI-ассистентов.

AI генерирует рабочий код быстро. Но «работает» не означает «безопасно». Типичные проблемы сгенерированного кода: авторизация на объектном уровне добавляется не всегда; rate limiting часто не включается по умолчанию; сообщения об ошибках могут быть избыточно информативными; заголовки безопасности не выставляются автоматически; секреты иногда оказываются в примерах конфигурации.

Вдобавок, PR с AI-написанным кодом нередко просматриваются быстро: «AI сгенерировал, тесты прошли — можно мержить». Диф читают не до конца. Новая зависимость приезжает без явного ревью. Служебные файлы и конфиги проверяют хуже всего.

Именно здесь имеет смысл дополнительный слой контроля, который анализирует конкретное изменение — не весь репозиторий целиком, а тот PR, который сейчас на ревью — и отвечает на вопрос: есть ли в этом изменении риск, блокирующий merge или требующий внимания перед релизом. Такой подход реализует HighVibe: проверка изменений в коде, конфигурации и зависимостях до слияния, с коротким понятным сигналом для команды вместо длинного отчёта, который никто не дочитывает.

Decision framework: что блокирует merge, что требует внимания, что можно принять

Не все риски одинаковы. Вот простая логика приоритизации для продуктовой команды.

Блокирует merge/релиз:

• Обнаруженный секрет (ключ, токен, пароль) в коде или конфиге.
• Новый API-эндпоинт без проверки авторизации на объектном уровне.
• Отсутствие аутентификации на эндпоинте, возвращающем чувствительные данные.
• Открытый CORS (*) на эндпоинте с сессионными данными.
• Debug-режим или подробные стек-трейсы в production-конфиге.

Требует внимания и явного решения:

• Отсутствие rate limiting на новом публичном эндпоинте.
• Новая зависимость с открытыми CVE.
• API, возвращающий больше полей, чем необходимо клиенту.
• Отсутствие логирования для нового эндпоинта.
• Эндпоинт без документации в API-реестре.

Можно принять с оговоркой:

• Расширенный CORS для партнёрских доменов — при условии явного whitelist и документированного решения.
• Зависимость с низким CVSS без доступного вектора атаки — с задачей на обновление.
• Отсутствие MFA на неадминистративном эндпоинте — при условии, что там нет чувствительных операций.

Что делать дальше: с чего начать, если пока ничего нет

Если продуктовая команда только начинает выстраивать API-безопасность и всё выше кажется огромным фронтом работы — хорошая новость: большинство критичных проблем закрываются базовыми мерами.

Рекомендуемая последовательность:

1. Составьте инвентарь. Начните с простого: у каждого API должен быть владелец, статус (активный / депрекейтный) и краткое описание данных, к которым он предоставляет доступ. Без этого невозможен следующий шаг.

1. Проверьте аутентификацию и авторизацию на критичных эндпоинтах. Возьмите пять самых чувствительных по данным эндпоинтов и проверьте: есть ли проверка прав на объектном уровне? Можно ли получить чужие данные, изменив ID?

1. Найдите и ротируйте секреты. Подключите автоматическое сканирование репозитория. Если обнаружены утечки — немедленная ротация, не только удаление из кода.

1. Настройте rate limiting на эндпоинтах аутентификации. Это самое быстрое действие с высоким влиянием.

1. Выставьте минимальные security-заголовки и проверьте CORS. Займёт час — закрывает класс типовых атак.

1. Убедитесь, что есть базовое логирование и хотя бы один алерт на аномалию. Даже простое оповещение о резком росте ошибок 401 — уже гораздо лучше, чем ничего.

Разберитесь с приоритетами, назначьте ответственных и встройте проверки в процесс ревью. API-безопасность — не разовый аудит, а регулярная практика команды.

Заключение

API-безопасность не требует экспертного AppSec-отдела, чтобы начать. Она требует системности: понимать, что развёрнуто, кто к этому имеет доступ и при каких условиях, что меняется в каждом релизе.

OWASP API Top 10 даёт исчерпывающую карту рисков. Реальная статистика инцидентов показывает, что большинство взломов эксплуатируют не экзотические zero-day, а базовые ошибки: отсутствие проверки авторизации, слабое управление токенами, открытый CORS, отсутствие rate limiting.

Семь зон из этого чек-листа — минимальная программа для продуктовой команды любого масштаба. Начните с инвентаря, закройте самые очевидные дыры в авторизации и аутентификации, настройте мониторинг. Остальное — итерационно.

И помните: «работает» не значит «безопасно». В особенности когда код пишется с помощью AI, дифы читаются быстро, а до релиза — часы.

Источники

[1] Raidiam — "API Security: The Definitive Guide for 2025 and Beyond" — https://www.raidiam.com/api-security-the-definitive-guide-for-2025-and-beyond

[2] Morgan Lewis Blog — "Study Finds Average Cost of Data Breaches Decreased Globally in 2025" — https://www.morganlewis.com/blogs/sourcingatmorganlewis/2026/04/study-finds-average-cost-of-data-breaches-decreased-globally-in-2025

[3] AppSec Santa — "API Security Statistics 2026: 55+ Key Facts & Data" — https://appsecsanta.com/research/api-security-statistics

[4] ФинТех РФ — "Стандарты безопасности открытых API, разработанные АФТ и ИнфоТеКС, опубликованы Банком России" — https://www.fintechru.org/press-center/news/standarty-bezopasnosti-otkrytykh-api-razrabotannye-aft-i-infoteks-opublikovany-bankom-rossii/

[5] IT SecExpo — "Проектирование и защита API" (материалы конференции, включая доклад Ozon Fintech об IDOR) — https://www.itsecexpo.ru/2025/program/api_security

[6] OWASP — "API Security Top 10 2023" — https://owasp.org/API-Security/editions/2023/en/0x00-toc/

[7] ApyGuard — "OWASP API Security Top 10 (2023): Every Vulnerability Explained With Fixes" — https://www.apyguard.com/resources/blog/owasp-api-security-top-10

[8] Equixly — "Shadow API: The Ant that Turns into an Elephant" — https://equixly.com/blog/2024/08/05/shadow-api/

[9] JPablo13 / Medium — "OWASP API9: How to Exploit Shadow and Zombie APIs" — https://medium.com/@jpablo13/owasp-api9-how-to-exploit-shadow-and-zombie-apis-improper-inventory-management-a2ccd60fdaaf

[10] SecureLayer7 — "Shadow APIs Explained: Risks, Detection, and Prevention" — https://blog.securelayer7.net/shadow-apis-explained-risks-detection-and-prevention/

[11] Practical DevSecOps — "API Security Best Practices to Follow in 2025" — https://www.practical-devsecops.com/api-security-best-practices/

[12] Raidiam — "API Security Checklist: Your Essential Guide to Protecting APIs in 2025" — https://www.raidiam.com/insights/api-security-checklist-your-essential-guide-to-protecting-apis-in-2025

[13] Salt Security — "OWASP API Security Top 10 2023 Explained" — https://salt.security/blog/owasp-api-security-top-10-explained

[14] BleepingComputer — "GitHub expands security tools after 39 million secrets leaked in 2024" — https://www.bleepingcomputer.com/news/security/github-expands-security-tools-after-39-million-secrets-leaked-in-2024/

[15] GitHub Blog — "GitHub found 39M secret leaks in 2024. Here's what we're doing to help" — https://github.blog/security/application-security/next-evolution-github-advanced-security/

[16] GitGuardian — "API Keys Security & Secrets Management Best Practices" — https://blog.gitguardian.com/secrets-api-management/

[17] Seeburger Blog — "API Security Breach: Examples, Costs & Prevention" — https://blog.seeburger.com/the-true-cost-of-api-security-breaches-examples-consequences-prevention/

[18] Fyld — "API Security Playbook: 10 Best Practices Developers Should Follow" — https://www.fyld.pt/blog/api-security-10-practices-developers/

[19] SecureLayer7 — "OWASP Top 10: Security Misconfiguration — CORS Vulnerability Patch" — https://blog.securelayer7.net/owasp-top-10-security-misconfiguration-5-cors-vulnerability-patch/

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

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

[22] CyCognito — "API Security: 2026 Guide to Threats, Challenges, and Best Practices" — https://www.cycognito.com/learn/api-security/