Какие бывают уязвимости API

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

Знаете ли вы реальные классы атак на API, а не общие слова про шифрование и сложные пароли, и умеете ли закрывать их средствами своего стека. Следом часто просят показать, где в Spring-приложении обычно появляется дыра в авторизации.

Как отвечать

Опирайтесь на OWASP API Security Top 10, актуальная редакция 2023 года:

• BOLA: первое место. GET /orders/42 отдаёт чужой заказ, потому что проверили только факт входа. Владельца проверяют для каждого объекта: в сервисном слое или через @PreAuthorize с выражением;
• сломанная аутентификация: нет лимита попыток входа, JWT без проверки подписи и срока, вечные токены;
• авторизация на уровне свойств: API отдаёт лишние поля или принимает их на запись (mass assignment). Классика: @RequestBody сразу в JPA-сущность, и клиент присылает "role": "ADMIN". Лечится отдельными DTO на вход и выход;
• неограниченное потребление ресурсов: нет лимитов на частоту, размер страницы, размер файла. Rate limiting на шлюзе или через Bucket4j;
• BFLA: обычный пользователь вызывает админский эндпоинт, потому что /admin/** забыли закрыть в SecurityFilterChain;
• SSRF: сервер ходит по URL из запроса во внутреннюю сеть или к метаданным облака;
• ошибки конфигурации: открытый Actuator (/actuator/env, /actuator/heapdump), стектрейсы в ответах, слишком широкий CORS;
• забытые версии API и слепое доверие ответам чужих API.

Инъекции в редакции 2023 отдельной строкой не выделены, но о них спросят: в JPQL и нативных запросах только параметры, без конкатенации. XML-парсеру отключайте DOCTYPE против XXE, в Jackson не включайте полиморфную десериализацию по имени класса из запроса.

Где спотыкаются

Называют только SQL-инъекции и DDoS, а про BOLA не слышали, хотя это самая частая находка в реальных API.

Считают, что HTTPS и аутентификация закрывают вопрос. Токен говорит, кто пришёл, но не даёт права читать чужой объект.

Возвращают сущность целиком и прячут поля на фронтенде. Всё, что пришло в ответе, видно в DevTools.