Перейти к основному содержимому

Уязвимости и атаки на API

Разработчику Архитектору

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

Чек-лист профилактики

Двенадцать практик "с чего начать" — HTTPS, OAuth, rate limit, gateway, валидация и др. — собраны в 12 советов по безопасности API.

Ниже в этой статье — каталог угроз и разбор типичных промахов.

Общая база: безопасность приложений. Интеграционная авторизация и практика Basic, Bearer, mTLS — 8.05.1121, 8.05.134.


Модель угроз

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


Каталог угроз

УгрозаСутьПримерМитигация
Broken Access Control / IDORДоступ к чужому объекту по ID; права из queryGET /orders/999 чужого заказа; GET /admin/users?isAdmin=trueПроверка владельца и роли на сервере, не только "есть JWT"
SQL / NoSQL / Command injectionВраждебный ввод в запрос' OR 1=1--, blind SLEEPТипы SQLi; параметры, ORM
Mass assignmentКлиент прислал лишние поля{"role":"admin"} в профилеDTO, явный allow-list полей
Open Redirect?next=http://evilФишинг с вашим доменомWhitelist URL редиректа
SSRFСервер дергает внутренний URLurl=http://169.254.169.254Блок private IP, исходящий proxy
XSS (через API → HTML)Неэкранированные данные в письме/админкеЧаще Stored; возможны Reflected и DOM-basedЭкранирование, CSP; см. три типа XSS
CSRFБраузер шлёт cookie без ведомаPOST с чужого сайта; смена пароля без re-authSameSite, anti-CSRF token
Brute forceПеребор паролей / OTPТысячи /loginRate limit, captcha, lockout
DoS / HTTP floodИсчерпание воркеровМедленные POSTRate limit, WAF, body size cap
Slowloris / slow POSTДержит соединения открытымиМедленная отправка телаТаймауты на прокси
Zip bombМаленький архив → гигабайтыРаспаковка без лимитаЛимит размера, streaming scan
Logic bombЗлоупотребление бизнес-правиломБесконечные бонусыИнварианты, аудит, лимиты
MITMПодслушивание каналаПубличный Wi‑FiTLS везде, HSTS
Утечка в ответеStack trace, внутренние ID500 с SQL в телеЕдиный error handler

IDOR — разбор типичного промаха

GET /api/v1/documents/550e8400-e29b-41d4-a716-446655440000
Authorization: Bearer <valid_user_A>

Сервер возвращает документ, если UUID существует, не проверяя, что документ принадлежит user A.

Правильно: SELECT … WHERE id = @id AND owner_id = @currentUser.

Тест: два пользователя, два объекта — ни один не читает чужой ID.


Rate limiting

УровеньГде
ГлобальныйAPI Gateway, Nginx limit_req
По пользователюMiddleware + Redis counter
По операцииСтроже на /login, /reset-password

Ответ при превышении: 429 Too Many Requests + по возможности Retry-After и X-RateLimit-*. Поток login → refresh → logout с rate limit на входе — аутентификация.

Token bucket — когда допустим кратковременный burst (мобильное приложение, пачка параллельных GET). Leaky bucket или очередь с фиксированной скоростью обработки — когда нужно защитить БД или внешний API от волны одновременных запросов. Sliding window (журнал или счётчик) — когда важна точность лимита "за последние N секунд" без провала на стыке минутных окон.

Разбор всех пяти алгоритмов (fixed window, sliding window log/counter, token bucket, leaky bucket) — §10 "12 концепций". Реализация счётчика в Redis — ZSET + Lua.


Заголовки и hardening

Минимальный набор для HTTP API за прокси:

  • Strict-Transport-Security
  • ограничение Content-Type на входе
  • не отдавать лишние заголовки (Server, внутренние версии)

Для браузерных клиентов — CORS и CSP на фронте.


Процесс в команде

  1. Threat modeling на новый endpoint (STRIDE-lite достаточно).
  2. Security-тесты в CI: известные IDOR/SQLi кейсы на staging.
  3. Пентест перед крупным релизом публичного API.
  4. Реагирование — блок токена, откат, post-mortem (наблюдаемость).

Связанные темы


Основа по протоколу

Базовый разбор HTTP и HTTPS находится в отдельной статье — HTTP как основа веб-интеграций.


Дополнение — практический минимум API hardening

Контроль доступа

  • Проверять права на уровне бизнес-объекта, а не только валидность токена.
  • Разделять роли чтения и изменения данных.
  • Ограничивать scope токенов под конкретные операции.

Безопасность запросов и ответов

  • Жёстко валидировать входные схемы.
  • Ограничивать размер тела запроса и глубину JSON.
  • Возвращать безопасные ошибки без внутренних деталей.

Наблюдаемость

  • Логировать неуспешные попытки доступа и аномальные паттерны.
  • Выделять отдельные алерты для brute force и скачков 4xx/5xx.
  • Хранить correlation-id для трассировки цепочки запросов.

Связанные статьи