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

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

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

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

JWT (JSON Web Token)

• Используйте случайный сложный ключ (JWT Secret), чтобы сделать брут форс токена бесполезным.
• Не полагайтесь на переданное в заголовках название алгоритма, лучше закрепите его константой на сервере (HS256 или RS256).
• Сделайте срок действия токена (TTL, RTTL) как можно короче.
• Не храните конфиденциальные данные в JWT, его можно легко декодировать..
• Избегайте хранения слишком большого количества данных. JWT обычно используется в header, и они имеют ограничение по размеру.

Доступ

• Установите ограничение на кол-во запросов в минуту (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, application/json и т.д.).
• Проверьте пользовательский ввод во избежание распространенных уязвимостей (например: XSS, SQL-инъекций, удаленное выполнение кода и т.д.).
• Не передавайте конфиденциальные данные (учетные данные, пароли, токены или ключи API) в URL-адресе, вместо него используйте стандартный заголовок Authorization.
• Используйте только шифрование на стороне сервера.
• Используйте единый API-шлюз, чтобы можно было настроить кеширование, ограничение на кол-во запросов, Spike Arrest, а также динамическое развертывание API.

Обработка

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

Ответ

• Отправляйте заголовок 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.
• Не возвращайте конфиденциальные данные, такие как учетные данные, пароли, токены.
• Возвращайте код состояния в соответствии с итогами обработки. (Например: 200 OK, 400 Bad Request, 401 Unauthorized, 405 Method Not Allowed и т.д.).

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

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

Мониторинг

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