Безопасность API в 2026 году: поверхность атаки, которую пентест часто упускает

Материал основан на разборе dev.to. Ниже — главное и выводы, которые стоит учитывать в SEO и маркетинге.

---

«API — это новый периметр. Только в отличие от старого периметра большинство организаций понятия не имеют, сколько API они запускают, кто к ним обращается и какие данные они раскрывают.» — Руководитель Red Team, финансовое учреждение из списка Fortune 100

Поверхность атаки сместилась. Кардинально. В 2026 году API-трафик составляет большую часть всего интернет-взаимодействия — и именно он является основным вектором утечек данных во всех секторах. Не фишинг. Не программы-вымогатели. API.

Взлом Optus: API. Утечка данных 5,4 миллиона пользователей Twitter: API. Раскрытие данных пользователей Peloton: API. Утечка 37 миллионов записей T-Mobile: API. Ни одна из этих атак не была изощрённой операцией государственного уровня. В каждом случае злоумышленник находил конечную точку API, понимал, что она делает, и эксплуатировал логическую уязвимость или брешь в контроле доступа, которую ни один традиционный сканер не обнаружил бы.

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

Мы погрузимся глубоко. Реальные техники атак, реальные полезные нагрузки и реальные цифры бизнес-ущерба показывают, почему API-безопасность больше нельзя воспринимать как разовый этап перед релизом. Для production-систем это должна быть непрерывная инженерная практика: инвентаризация, наблюдаемость, контроль доступа и постоянная перепроверка поведения API.

Если вам нужен практический пример того, как закрывать административный доступ, ограничивать частоту запросов и не оставлять лишних привилегий в продакшене, посмотрите материал про безопасные Firebase Cloud Functions с правами администратора.

Содержание

Непрерывный подход к безопасности API

1. The API Explosion

Среднестатистическое предприятие использует более 900 API. У большинства крупных организаций нет полного их перечня. Команды разработчиков ежедневно выпускают новые конечные точки. Микросервисы порождают внутренние API, которые никогда не документируются официально. Мобильные приложения обращаются к недокументированным бэкенд-конечным точкам. Сторонние интеграции вводят API-поверхности, которые вы не создавали и не можете полностью проверить.

Это не технологическая проблема. Это организационная и архитектурная проблема — и традиционные инструменты безопасности не были рассчитаны на неё.

1.1 Почему API ломаются иначе, чем веб-приложения

Классические уязвимости веб-приложений — XSS, CSRF, кликджекинг — в основном реализуются через браузер. API взаимодействуют машина-с-машиной. Здесь нет браузера, применяющего политику одного источника, нет CORS для неправильной настройки, нет отрисованного DOM для инъекций. Поверхность атаки полностью логическая: контроль доступа, фильтрация данных, ограничение частоты запросов, аутентификация и бизнес-логика.

Это означает следующее:

Автоматизированные сканеры находят очень мало. Сканер, отправляющий <script>alert(1)</script> в поле JSON API, получит ответ 400 и двинется дальше. Реальные уязвимости кроются в том, что API делает с корректными, правильно типизированными входными данными.

Специалисты по пентесту должны понимать приложение, а не только протокол. Наиболее ценные находки в API появляются в результате чтения спецификаций OpenAPI, обратной разработки мобильных приложений, трассировки потоков аутентификации и понимания бизнес-домена.

Защита требует поведенческого интеллекта, а не только сопоставления сигнатур. Злоумышленник, делающий 10 000 последовательных запросов к /api/users/{id}, на уровне пакетов выглядит как обычный API-трафик. Для его идентификации как перебора BOLA требуется семантическое понимание.

1.2 Реальная оценка бизнес-ущерба

Давайте подкрепим это цифрами, потому что аргументы в пользу инвестиций весомы:

Средняя стоимость утечки данных, связанной с API, в 2025 году составила 4,8 млн долларов — выше общего среднего показателя стоимости утечки

Организациям, пострадавшим от утечки через API, в среднем требовалось 287 дней на её выявление и локализацию

В регулируемых отраслях (финансовые услуги, здравоохранение) утечки через API влекут дополнительные регуляторные риски: штрафы по GDPR, санкции по HIPAA, провалы аудита PCI-DSS

Простой API из-за DDoS-атак или атак на исчерпание ресурсов обходится SaaS-компаниям в среднем в 300 тысяч долларов в час в виде потерянной выручки и расходов на поддержку

Это не теоретические риски. Это статьи расходов, о которых всё чаще спрашивают финансовые директора, советы директоров и регуляторы.

2. BOLA / IDOR: по-прежнему наиболее критичная уязвимость API

Broken Object Level Authorization — BOLA, или IDOR (Insecure Direct Object Reference, небезопасная прямая ссылка на объект) в терминологии традиционной веб-безопасности — занимает первое место в OWASP API Security Top 10 в каждом издании с момента публикации. Именно она ответственна за большинство масштабных утечек данных через API. И именно она наиболее последовательно недооценивается в рамках пентест-скоупов.

2.1 Анатомия уязвимости BOLA

GET /api/v1/accounts/38291/transactions HTTP / 1.1 Authorization : Bearer eyJhbGciOiJIUzI1NiJ9… Host : api.fintech-app.com Enter fullscreen mode Exit fullscreen mode Приложение аутентифицирует пользователя через JWT. Но проверяет ли оно, что аккаунт 38291 принадлежит именно этому пользователю? Если нет, злоумышленник, который изменит 38291 на 38292, 38293 и так далее, сможет перебором получить историю транзакций каждого аккаунта.

2.2 BOLA в масштабе: проблема перебора

Реальный ущерб от BOLA, как правило, возникает не от одного злоумышленника, вручную меняющего идентификаторы. Речь идёт об автоматизированном переборе — скриптовой итерации по диапазонам ID для массового сбора данных.

3. Broken Function-Level Authorization: вертикальная эскалация привилегий

Если BOLA — это горизонтальная уязвимость (пользователь A получает доступ к данным пользователя B), то Broken Function-Level Authorization (BFLA) — вертикальная: обычный пользователь получает доступ к функциям, зарезервированным для администраторов.

3.1 Скрытый Admin API

4. Mass Assignment: когда ваш ORM становится бэкдором

Уязвимости Mass Assignment возникают, когда эндпоинт API автоматически привязывает поля тела запроса к свойствам модели, не указывая явно, какие поля разрешено обновлять.

4.1 Классическая атака Mass Assignment

// Предполагается: пользователь обновляет отображаемое имя // Тело запроса: { «name»: «John Doe» } // Что отправляет злоумышленник: { «name»: «John Doe», «role»: «admin», «verified»: true, «credits»: 999999 } app . put ( ‘ /api/v1/users/me ‘ , authenticate , async ( req , res ) => { // ОПАСНО: Распространяет всё тело запроса на объект пользователя await User . findByIdAndUpdate ( req . user . id , req . body ); res . json ({ success : true }); }); Enter fullscreen mode Exit fullscreen mode // БЕЗОПАСНО: Явный список разрешённых для обновления полей const ALLOWED_USER_FIELDS = [ ‘ name ‘ , ‘ bio ‘ , ‘ avatar_url ‘ , ‘ timezone ‘ ]; app . put ( ‘ /api/v1/users/me ‘ , authenticate , async ( req , res ) => { const updates = pick ( req . body , ALLOWED_USER_FIELDS ); // lodash pick await User . findByIdAndUpdate ( req . user . id , updates ); res . json ({ success : true }); }); Enter fullscreen mode Exit fullscreen mode

4.2 Mass Assignment в Mongoose

// ОПАСНО: Нет защиты на уровне схемы const UserSchema = new mongoose . Schema ({ name : String , email : String , role : { type : String , default : ‘ user ‘ }, // Никогда не должно устанавливаться пользователем isVerified : { type : Boolean , default : false } // Никогда не должно устанавливаться пользователем }); Enter fullscreen mode Exit fullscreen mode // БЕЗОПАСНЕЕ: Используйте select: false для чувствительных полей + allowlisting на уровне приложения const UserSchema = new mongoose . Schema ({ name : String , email : String , role : { type : String , default : ‘ user ‘ , select : false }, isVerified : { type : Boolean , default : false , select : false } }); Enter fullscreen mode Exit fullscreen mode

4.3 Бизнес-последствия

Уязвимости Mass Assignment привели к ряду заметных реальных инцидентов. В 2012 году в GitHub была обнаружена уязвимость Mass Assignment, позволившая исследователю добавить свой SSH-ключ в любой репозиторий — включая сам репозиторий Rails. Злоумышленник (исследователь в области белой шляпы) продемонстрировал проблему, отправив коммит. Бизнес-последствия злонамеренной эксплуатации были бы катастрофическими: произвольное выполнение кода в CI/CD-пайплайне любого репозитория.

В SaaS-приложениях Mass Assignment, как правило, проявляется в том, что пользователи самостоятельно повышают свой уровень подписки, отключают биллинг, присваивают себе роли администраторов или получают доступ к премиум-функциям без оплаты — прямой финансовый ущерб, который зачастую сложно обнаружить без тщательного ведения журналов аудита.

5. Избыточное раскрытие данных: API, который говорит слишком много

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

5.1 Паттерн избыточного раскрытия

## 6. Ограничение частоты запросов и атаки на исчерпание ресурсов
API, в которых отсутствует надлежащее ограничение частоты запросов, уязвимы к широкому спектру атак — от брутфорса учётных данных до DDoS на уровне приложения и массового перебора.
### 6.1 Подстановка учётных данных при отсутствии ограничений частоты запросов

{ «password»: «Password123» }

При отсутствии ограничения частоты запросов злоумышленник может перебирать миллионы комбинаций учётных данных. Взлом клиентов Snowflake в 2024 году — затронувший Ticketmaster, Santander и других — был частично обусловлен подстановкой учётных данных против API с недостаточным ограничением частоты запросов.
Эффективное ограничение частоты запросов должно быть:
- **По IP** — но с учётом того, что злоумышленники используют сети резидентных прокси с миллионами IP-адресов
- **По аккаунту** — блокировать или замедлять аккаунт после N неудачных попыток, независимо от исходного IP
- **По действию** — разные лимиты для входа в систему (строгие) и операций чтения (мягкие)
- **Глобально согласованным** — применяться на уровне API-шлюза, а не на уровне отдельных экземпляров, чтобы исключить обход путём обращения к конкретным узлам бэкенда
### 6.2 Атака перебора через SMS/OTP
Тонкая атака на исчерпание ресурсов нацелена на API, отправляющие SMS-коды OTP:

{«phone»: «+1-555-000-0001»}

{«phone»: «+1-555-000-0002»}

7. Специфические векторы атак на GraphQL

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

7.1 Интроспекция: подарок для злоумышленников

По умолчанию эндпоинты GraphQL раскрывают полную схему через запросы интроспекции. Злоумышленник может составить карту всей вашей модели данных, всех доступных запросов и мутаций, всех типов и их полей — в одном запросе.

## 8. Неправильное управление API-ключами: учётные данные на виду
API-ключи — это механизм аутентификации для взаимодействия машина-машина. При этом они систематически используются неправильно: жёстко прописываются в исходном коде, коммитятся в репозитории, встраиваются в мобильные приложения, записываются в логи в открытом виде и раскрываются в JavaScript-бандлах.
### 8.1 Проблема сканирования секретов на GitHub
Исследования неизменно показывают, что ежедневно в публичные репозитории GitHub коммитятся десятки тысяч API-ключей. Промежуток между коммитом и эксплуатацией нередко составляет менее 4 минут — автоматизированные боты сканируют публичный поток событий GitHub в режиме реального времени.
### 8.2 API-ключи в мобильных приложениях
Мобильные приложения нередко содержат встроенные API-ключи, которые можно извлечь с помощью статического анализа:

9. Злоупотребление вебхуками и подделка обратных вызовов

Вебхуки — HTTP-обратные вызовы, уведомляющие вашу систему о событиях в сторонних платформах, — создают обратную поверхность атаки на API. Теперь ваше приложение получает HTTP-запросы от внешних источников и доверяет им.

9.1 Проблема непроверенных вебхуков

## 10. Теневые API и зомби-эндпоинты: проблема инвентаризации
Одна из наиболее недооценённых проблем в безопасности API — это проблема инвентаризации: невозможно защитить то, о существовании чего вы не знаете.
### 10.1 Что такое теневые и зомби-API?
**Теневые API**: эндпоинты, которые существуют в продакшене, но не задокументированы, отсутствуют в реестре API-шлюза и не мониторятся. Они часто создаются в ходе ускоренных циклов разработки, тестирования или разработчиками, обошедшими стандартный процесс развёртывания.
**Зомби-API**: эндпоинты, которые когда-то были официальными, но больше не поддерживаются — устаревшие версии, унаследованные интеграции, удалённые функции, серверные маршруты которых так и не были удалены.
Обе категории объединяет одна критическая характеристика: они не получают никакого внимания с точки зрения безопасности. Они не обновляются патчами безопасности. Они не охвачены правилами WAF. Они не мониторятся на предмет аномального трафика. И зачастую они работают на более старом, более уязвимом коде.
### 10.2 Обнаружение теневых API в ходе пентестов

11. Неправильные конфигурации JWT и OAuth в аутентификации API

Аутентификация — это парадный вход вашего API. Самая изощрённая находка BOLA теряет смысл, если злоумышленник может подделать токены аутентификации. JWT и OAuth — доминирующие стандарты аутентификации API — имеют хорошо задокументированные подводные камни реализации, которые продолжают встречаться в продакшен-системах.

11.1 Атака с алгоритмом none

## 12. Уязвимости бизнес-логики: то, что сканеры никогда не найдут
Уязвимости бизнес-логики — это наиболее ценные находки в рамках работ по безопасности API. Их невозможно обнаружить автоматизированными сканерами. Для их выявления необходимо понимать предметную область приложения, его предполагаемое поведение и разрыв между тем, что API позволяет делать, и тем, что он должен позволять.
### 12.1 Манипуляция ценами через подмену параметров API

13. Непрерывный подход к безопасности API

Инженеры по безопасности и пентестеры понимают разницу между запуском сканера и реальной оценкой безопасности. Сканер находит известные паттерны. Квалифицированный специалист находит намерение — разрывы между тем, что система делает, и тем, что она должна делать. Поэтому зрелая программа API-безопасности должна дополнять сканеры анализом кода, журналов и поведения запросов.

13.1 Анализ кода с приоритетом API

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

Отсутствующей аутентификации — конечных точек, доступных без действительного токена

Отсутствующей авторизации — аутентифицированных конечных точек без проверок владения объектом на уровне объекта (BOLA)

Непоследовательной авторизации — конечных точек, где авторизация применяется для одних HTTP-методов, но не для других

Нарушений доверия к схеме — полей, которые должны быть авторитетными на стороне сервера, но принимаются из клиентского ввода (массовое присвоение, манипуляция ценами)

Избыточных полей в ответах — сериализаторов ответов, включающих поля, превышающие объявленную классификацию данных для конечной точки

13.2 Обнаружение расхождений со спецификацией OpenAPI

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

13.3 Непрерывный мониторинг API в режиме реального времени

Помимо анализа кода, такой контур должен интегрироваться с API-шлюзом или сервисной сеткой для анализа паттернов производственного трафика — выявляя:

Попытки перебора: последовательный доступ к идентификаторам объектов с аномальной скоростью

Аномальные комбинации параметров: запросы с необычными комбинациями полей, которые могут указывать на зондирование

Паттерны эскалации области видимости: токены, используемые для вызова конечных точек за пределами объявленной области видимости

Аномалии схемы: тела запросов, включающие необъявленные поля (попытки массового присвоения)

Отклонение от базовой линии: значительное увеличение частоты ошибок, размеров ответов или частоты запросов на конечную точку

13.4 Усиление пентестов

Для инженеров по безопасности и пентестеров такой подход служит мультипликатором силы:

До начала работ: сформируйте приоритизированную карту конечных точек с наибольшим риском, прежде чем открывать Burp Suite. Не тратьте время на конечные точки, которые заведомо безопасны.

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

После завершения работ: используйте непрерывный мониторинг для проверки того, что находки устранены и остаются устранёнными в будущих развёртываниях.

14. Заключение: от точечного тестирования к непрерывной аналитике API

Ежегодный тест на проникновение — это не стратегия безопасности. Это снимок. Пятидневное взаимодействие с приложением, которое выпускает 50 пул-реквестов в неделю, пропустит уязвимость, введённую на 6-й день спринта после того, как пентестеры ушли домой.

Организации, побеждающие в борьбе за безопасность API, — это не те, кто проводит больше тестов на проникновение. Это те, кто сделал безопасность непрерывным, измеримым свойством своего процесса разработки API — встроенным в цикл проверки пул-реквестов, обеспечиваемым автоматизированным анализом и отслеживаемым в режиме реального времени в производственной среде.

Итог здесь в другом: API-безопасность должна работать на скорости современной разработки. Лучшие результаты даёт не один сканер и не один пентест, а связка инвентаризации, анализа кода, поведенческого мониторинга и ручной экспертизы.

Поверхность атаки растёт каждый день. Вопрос в том, растёт ли вместе с ней ваша видимость.