Контрольный список безопасности API

Чеклист наиболее важных контрмер по безопасности при разработке, тестировании и выпуске вашего API.

Аутентификация

Не используйте Basic Auth. Используйте стандартную проверку подлинности.
Не изобретайте велосипед для аутентификации, создании токенов, хранения паролей. Используйте стандарты, проверенные библиотеки.
Используйте Max Retry и функции jail во время аутентификации.
Используйте шифрование для всех конфиденциальных данных.

Доступ

Установите ограничение на кол-во запросов в минуту (Throttling, RPM-Limit), чтобы избежать DDoS / Brute Force атак.
Используйте HTTPS на стороне сервера, чтобы избежать MITM (Man In The Middle Attack / атака "человек посередине").
Используйте заголовок HSTS (HTTP Strict Transport Security) с SSL, чтобы избежать атаки SSL Strip (перехват SSL соединений).
Отключите списки каталогов.
Для частных API, разрешите доступ только с IP-адресов/хостов из белого списка.

Авторизация

OAuth

Всегда проверяйте redirect_uri на стороне сервера, чтобы разрешать только URL-адреса из белых списков (whitelist).
Всегда старайтесь использовать одноразовый code, а не токены (не использовать response_type=token).
Используйте параметр state со случайным хешем, чтобы предотвратить CSRF в процессе аутентификации OAuth.
Определите scope по умолчанию, а также проверяйте параметры для каждого приложения.

Запрос

Используйте соответствующий HTTP-метод в соответствии с операцией: GET (чтение), POST (создание), PUT / PATCH (замена / обновление) и DELETE (удаление), а также ответьте 405 Method Not Allowed, если запрошенный метод не подходит для запрашиваемого ресурса.
Проверяй тип данных в заголовке Accept, чтобы разрешить только поддерживаемые форматы (например, application/xml, application/json и т.д.) И отвечайте 406 Not Acceptable, если тип не поддерживается.
Проверяйте, сможете ли вы обработать тип получаемых данных (например, application/x-www-form-urlencoded, multipart/form-data, и т.д.).

Обработка

Проверьте, защищены ли все точки входа аутентификацией, чтобы не нарушить процедуру проверки подлинности.
Следует избегать ID собственного ресурса. Используйте /me/orders вместо /user/654321/orders.
Не используйте автоинкремент для ID. Вместо этого используйте UUID.
Если вы разбираете XML-файлы, убедитесь, что парсинг сущностей выключен, чтобы избежать XXE (XML external entity).
Если вы разбираете XML-файлы, убедитесь, что расширение сущности выключено, чтобы избежать Billion Laughs / XML bomb через атаку экспоненциального расширения сущностей.
Используйте CDN для загрузки файлов.
Если вы имеете дело с огромным количеством данных, используйте Workers and Queues, чтобы обрабатывать как можно больше в фоновом режиме и быстро возвращать ответ, чтобы избежать блокирования HTTP.
Не забудьте выключить режим отладки (debug).

Ответ

Отправляйте заголовок X-Content-Type-Options: nosniff.
Отправляйте заголовок X-Frame-Options: deny.
Отправляйте заголовок Content-Security-Policy: default-src 'none'.
Удалите заголовки, которые могут помочь злоумышленнику в исследовании вашего ресурса на уязвимости - X-Powered-By, Server, X-AspNet-Version и т.д.
Зафиксируйте Content-Type для вашего ответа, если вы возвращаете application/json, тогда запрос должен быть в application/json.
Do not return overly specific error messages to the client that could reveal implementation details, use generic messages instead, and log detailed information only on the server side.

Непрерывная интеграция и Непрерывная доставка (CI & CD)

Проверяйте ваш проект во время CI/CD. Покрывайте код unit/интеграционными тестами.
Используйте процесс проверки кода (Code Review) коллегами. Не апрувьте сами себя (no Self-Approval).
Убедитесь, что ваше приложение сканируются с помощью антивирусов перед отправкой в прод, включая библиотеки и другие зависимости.
Постоянно запускайте тесты безопасности (статический/динамический анализ) вашего кода.
Проверьте свои зависимости (как программное обеспечение и ОС) на наличие известных уязвимостей.
Сделайте возможным быстрый откат на предыдущую версию.

Мониторинг

Используйте централизованные входы для всех служб и компонентов.
Используйте агенты для мониторинга всего трафика, ошибок, запросов, и ответов.
Используйте оповещения для SMS, Slack, электронной почты, Telegram, Kibana, Cloudwatch, и т.д.
Убедитесь, что вы не регистрируете какие-либо конфиденциальные данные, такие как кредитные карты, пароли, PIN-коды, и т.д.
Используйте систему IDS и/или IPS для мониторинга запросов и экземпляров API.

Смотрите также:

yosriady/api-development-tools - Сбор полезных ресурсов для создания RESTful HTTP+JSON API.
You don't need JWT, just use a randomly generated API key. If you need asymmetric encryption or tamper prevention, here are some alternatives to JWT.

API Security Best Practices (Advanced)

Rate Limiting & Abuse Prevention

Implement sliding window rate limiting per API key and IP.
Use exponential backoff for repeated failed authentication attempts.
Implement CAPTCHA or proof-of-work challenges after suspicious activity.
Monitor and alert on unusual API usage patterns (time, volume, endpoints).

GraphQL-Specific Security

Disable introspection in production environments.
Implement query depth limiting to prevent nested query attacks.
Use query cost analysis to prevent resource exhaustion.
Whitelist allowed queries in production when possible.

Secrets Management

Rotate API keys and secrets on a regular schedule.
Use hardware security modules (HSM) for signing operations.
Implement secret scanning in CI/CD pipelines.
Never commit secrets to version control - use environment variables or secret managers.

Zero Trust Architecture

Implement mutual TLS (mTLS) for service-to-service communication.
Validate all requests even from internal services.
Use short-lived tokens with automatic refresh.
Implement request signing for sensitive operations.

Вклад

Не стесняйтесь вносить вклад, открывая этот репозиторий, внося некоторые изменения и отправляя Pull Requests. По любым вопросам напишите нам письмо по адресу [email protected].

API-Security-Checklist

Популярное