Безопасность API: лучшие практики защиты

API документацию (Application Programming Interface) стал основой современных веб-приложений. Через API работают мобильные приложения, SPA-сайты, интеграции между сервисами и IoT-устройства. Но с ростом использования API растёт и количество атак на них. В этой статье разберём ключевые практики защиты API от наиболее распространённых угроз.

Почему безопасность API важна

По данным OWASP, API входят в топ-10 наиболее уязвимых компонентов веб-приложений. Специфика API в том, что они предоставляют прямой доступ к данным и бизнес-логике, минуя пользовательский интерфейс.

Типичные последствия компрометации API:

• Утечка персональных данных пользователей
• Несанкционированный доступ к функциональности
• Финансовые потери из-за злоупотребления сервисом
• Репутационный ущерб и юридические последствия
• Нарушение регуляторных требований (GDPR, 152-ФЗ)

Аутентификация и авторизация

OAuth 2.0 и OpenID Connect

OAuth 2.0 — стандарт авторизации, позволяющий приложениям получать ограниченный доступ к ресурсам пользователя без передачи пароля. OpenID Connect добавляет слой аутентификации поверх OAuth 2.0.

Ключевые рекомендации:

• Используйте flow Authorization Code с PKCE для публичных клиентов (SPA, мобильные приложения)
• Не используйте Implicit Flow — он устарел и небезопасен
• Храните токены безопасно: httpOnly cookies для веб-приложений, secure storage для мобильных
• Устанавливайте короткий срок жизни access-токенов (15–30 минут)
• Реализуйте ротацию refresh-токенов

JWT (JSON Web Tokens)

JWT широко используется для передачи информации об аутентификации. Однако неправильное использование JWT создаёт серьёзные уязвимости:

API-ключи

API-ключи подходят для идентификации приложения, но не для аутентификации пользователя. Рекомендации:

• Передавайте ключи через заголовок Authorization или кастомный заголовок, не через URL
• Реализуйте возможность отзыва и ротации ключей
• Ограничивайте ключи по IP геолокацию и доменам, где возможно
• Никогда не коммитьте ключи в репозиторий — используйте переменные окружения

Rate Limiting — ограничение частоты запросов

Rate limiting защищает API от злоупотреблений, DDoS-атак и брутфорса. Без ограничений один клиент может перегрузить сервер или перебрать все возможные значения.

Стратегии rate limiting

• Fixed window — фиксированное окно (например, 100 запросов в минуту). Простая реализация, но возможен burst на границе окон
• Sliding window — скользящее окно, более равномерное распределение
• Token bucket — накопление «токенов», позволяющее короткие burst-ы. Самый гибкий подход
• Leaky bucket — стабильная скорость обработки, очередь для burst-ов

Заголовки rate limiting

Информируйте клиентов о лимитах через стандартные заголовки:

X-RateLimit-Limit: 100
X-RateLimit-Remaining: 42
X-RateLimit-Reset: 1678886400
Retry-After: 30

При превышении лимита возвращайте HTTP 429 (Too Many Requests) с заголовком Retry-After.

CORS — Cross-Origin Resource Sharing

CORS определяет, какие домены могут обращаться к вашему API из браузера. Неправильная настройка CORS — одна из самых распространённых уязвимостей API.

Критически важные правила:

• Никогда не используйте Access-Control-Allow-Origin: * для API с аутентификацией
• Поддерживайте белый список разрешённых доменов
• Не отражайте Origin из запроса в ответе без проверки
• Ограничивайте Access-Control-Allow-Methods только необходимыми методами
• Устанавливайте Access-Control-Max-Age для кеширования preflight-запросов

Проверить CORS-заголовки вашего API можно с помощью анализатора HTTP-заголовков enterno.io.

HTTPS и TLS

Все API-запросы должны проходить через SSL/TLS проверку. Это не рекомендация, а требование. HTTP-трафик может быть перехвачен и модифицирован в любой точке между клиентом и сервером.

Рекомендации по настройке TLS:

• Используйте TLS 1.2 как минимум, предпочтительно TLS 1.3
• Отключите устаревшие протоколы: SSL 3.0, TLS 1.0, TLS 1.1
• Настройте HSTS (HTTP Strict Transport Security) с длительным max-age
• Используйте Certificate Pinning для мобильных приложений
• Регулярно проверяйте конфигурацию SSL через SSL-чекер enterno.io

Валидация входных данных

Каждый параметр API-запроса — потенциальный вектор атаки. Никогда не доверяйте данным от клиента.

Правила валидации

• Валидируйте тип, формат, длину и диапазон каждого параметра
• Используйте схемы валидации (JSON Schema, Zod, Joi, Pydantic)
• Отклоняйте запросы с неожиданными полями
• Санитизируйте строки для предотвращения SQL-инъекций и XSS
• Ограничивайте размер тела запроса
• Проверяйте Content-Type заголовок

Пример валидации с JSON Schema

{
  "type": "object",
  "required": ["email", "name"],
  "properties": {
    "email": {
      "type": "string",
      "format": "email",
      "maxLength": 255
    },
    "name": {
      "type": "string",
      "minLength": 1,
      "maxLength": 100,
      "pattern": "^[\\p{L}\\s-]+$"
    },
    "age": {
      "type": "integer",
      "minimum": 0,
      "maximum": 150
    }
  },
  "additionalProperties": false
}

Защита от типичных атак

Broken Object Level Authorization (BOLA)

Самая распространённая уязвимость API по OWASP API Security Top 10. Атакующий изменяет ID объекта в запросе и получает доступ к чужим данным.

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

Mass Assignment

Клиент отправляет поля, которые не должен изменять (например, role: "admin" или price: 0). Защита: явно определяйте список допустимых полей для каждого эндпоинта.

Excessive Data Exposure

API возвращает больше данных, чем нужно клиенту, полагаясь на фронтенд для фильтрации. Защита: возвращайте только необходимые поля, используйте DTO (Data Transfer Objects).

Логирование и мониторинг

Без адекватного логирования вы не обнаружите атаку и не сможете провести расследование.

Что логировать:

• Все попытки аутентификации (успешные и неудачные)
• Изменения прав доступа
• Попытки доступа к чужим ресурсам
• Превышение rate limit
• Ошибки валидации входных данных
• Серверные ошибки (500)

Чего не логировать: пароли, токены, номера карт, персональные данные в открытом виде.

Чек-лист безопасности API

1. Все эндпоинты работают через HTTPS
2. Аутентификация реализована через OAuth 2.0 или JWT с правильной конфигурацией
3. Авторизация проверяется для каждого ресурса (BOLA-защита)
4. Rate limiting настроен на всех публичных эндпоинтах
5. CORS корректно ограничивает разрешённые домены
6. Все входные данные валидируются по схеме
7. API не возвращает лишние данные
8. Логирование охватывает все важные события
9. API-ключи и секреты хранятся безопасно
10. Документация API актуальна и не раскрывает внутреннюю архитектуру