Введение
Мир всё больше опирается на API — они соединяют мобильные приложения с серверами, связывают микросервисы, обеспечивают интеграции между продуктами. Но именно API становятся главным «входом» для атакующих.
Организация OWASP (Open Web Application Security Project) составила список из 10 самых критичных уязвимостей API. Этот список называют OWASP API Security Top 10.
Разберём каждую уязвимость: что это, как она проявляется, примеры из жизни и как защититься.
🔟 OWASP API Security Top 10 (2023)
1. BOLA (Broken Object Level Authorization)
Суть: атакующий получает доступ к чужим объектам (например, к данным других пользователей).
Пример:
GET /api/users/123 → возвращает профиль пользователя с ID=123
Если злоумышленник поменяет 123 на 124, он может увидеть чужие данные.
Как защититься: проверять авторизацию на каждый запрос к объекту, а не только на уровне «пользователь вошёл в систему».
2. Broken Authentication
Суть: слабая или неправильно реализованная аутентификация.
Пример:
- Простые пароли (
123456) - Токены, которые не истекают
- JWT без подписи
Как защититься:
- Использовать современные протоколы (OAuth2, OpenID Connect)
- Ограничивать время жизни токенов
- Включать MFA (многофакторку).
3. BOPLA (Broken Object Property Level Authorization)
Суть: доступ к полям объекта, к которым нельзя.
Пример:
PATCH /api/users/123
{
"username": "alex",
"isAdmin": true
}
Если сервер не проверяет право менять isAdmin, злоумышленник сам себя сделает админом.
Как защититься: жёстко контролировать, какие поля может менять/читать конкретная роль.
4. Unrestricted Resource Consumption (DoS)
Суть: API позволяет «забить» сервер слишком тяжёлыми запросами.
Пример:
GET /api/logs?limit=1000000
Если нет лимитов, сервер рухнет.
Как защититься:
- Вводить rate limiting
- Ограничивать размер ответа и глубину пагинации
- Использовать кэширование.
5. Broken Function Level Authorization
Суть: обычный пользователь вызывает админский эндпоинт.
Пример:
POST /api/admin/deleteUser?id=123
Если сервер не проверяет роль, злоумышленник сможет удалить чужого юзера.
Как защититься:
- Проверять роли и права на уровне бизнес-логики
- Не полагаться только на скрытие эндпоинтов.
6. Mass Assignment
Суть: злоумышленник передаёт лишние поля в JSON, и они записываются в базу.
Пример:
POST /api/register
{
"username": "john",
"password": "12345",
"role": "admin"
}
Если backend автоматически маппит JSON → объект, то злоумышленник получит админку.
Как защититься:
- Явно описывать список разрешённых полей (allowlist)
- Игнорировать неизвестные поля.
7. Security Misconfiguration
Суть: неверные настройки безопасности.
Примеры:
- Swagger открыт в продакшене без авторизации
- Секреты хранятся в git
- CORS открыт для всех (
*)
Как защититься:
- Проверять конфиги перед релизом
- Делать пентесты
- Использовать автоматические сканеры.
8. Injection (SQL, NoSQL, Command Injection)
Суть: данные пользователя подставляются в запросы без фильтрации.
Пример SQL-инъекции:
SELECT * FROM users WHERE id = '123 OR 1=1';
Пример NoSQL-инъекции (MongoDB):
{ "username": { "$ne": null }, "password": { "$ne": null } }
Как защититься:
- Использовать параметризованные запросы
- Никогда не вставлять данные пользователя напрямую.
9. Improper Asset Management
Суть: старые или неиспользуемые API остаются доступными.
Пример:
/api/v1/users(старый, уязвимый)/api/v2/users(новый, защищённый)
Если старый API не закрыт — его можно эксплуатировать.
Как защититься:
- Удалять устаревшие API
- Вести документацию и версионирование
- Использовать API Gateway.
10. Insufficient Logging & Monitoring
Суть: атаки остаются незамеченными.
Пример:
Злоумышленник делает сотни запросов на перебор токенов, но логи не фиксируют аномалии.
Как защититься:
- Логировать все подозрительные действия
- Настроить алерты в SIEM/ELK
- Регулярно проводить анализ логов.
✅ Итог
- BOLA и BOPLA — самые частые уязвимости в API.
- Большинство проблем связано с неправильной авторизацией и плохой конфигурацией.
- Чтобы защитить API, нужно:
- Проверять доступ на уровне объектов и свойств
- Ограничивать ресурсы
- Делать аудит и мониторинг
API — это «дверь» в бизнес-логику компании. Если её не закрыть — рано или поздно её откроют.