Безопасность API и фильтрация запросов

1) Зачем это нужно

API — внешняя и внутренняя граница платформы. Любая ошибка в аутентификации, авторизации, валидации или нормализации запросов превращается в эксплуатацию уязвимостей (BOLA/IDOR, injection, SSRF, массовые переборы, ресурсное истощение). Цель: создать многоуровневую защиту (defense-in-depth) от периметра до бизнес-правил, с измеримыми SLO и контролем рисков.

2) Инвентаризация и классификация API

Каталог API: реестр всех сервисов/эндпоинтов, владельцы, версии, типы клиентов (web, mobile, партнеры), режим (публичный/партнерский/внутренний), PII/финданные.
Критичность: High (финансовые операции/авторизация), Medium (чтение профиля), Low (публичные справочники).
Поверхность атаки: REST, GraphQL, gRPC, WebSocket, webhooks.
Статус: prod/staging/experimental, политика депрекейта, срок жизни токенов/ключей.
Shadow/заброшенные API: обнаружение через ингрест логов, eBPF/Service Mesh телеметрию, сравнение с каталогом.

3) Модель угроз (кратко)

Идентификация: угон токенов, фиксация сессии, MitM, replay.
Авторизация: BOLA/IDOR, горизонтальная/вертикальная эскалация.
Ввод: инъекции (SQL/NoSQL/LDAP), шаблонные/серилизационные, path traversal, заголовки.
Трафик: DDoS/L7-флуды, медленные запросы, фантомные ретраи.
Интеграции: небезопасные webhooks, SSRF через URL-параметры, загрузки файлов/сканов.
Логика: злоупотребление бонусами, гонки, несогласованность идемпотентности.

4) Базовый стандарт безопасности (минимум)

1. TLS 1.2+ повсюду; HSTS; отключены слабые шифры.
2. Аутентификация: OAuth2/OIDC для клиентов, mTLS/или HMAC — сервис-к-сервис.
3. Авторизация: централизованный PDP (RBAC/ABAC), проверка на объектном уровне (BOLA).
4. Валидация: строгая схема (OpenAPI/JSON Schema/Protobuf), отказ при лишних полях.
5. Лимиты: rate/quotas + burst, пер-клиент/пер-IP/пер-токен.
6. Идемпотентность на write-операциях, защита от повторов/гонок.
7. WAF/гейтвей-фильтрация: нормализация путей/заголовков, deny-листы, блок payload-анти-паттернов.
8. Секреты: KMS/Vault, ротация ключей/сертификатов, контроль утечек.
9. Наблюдаемость: трассинг, аудит-логи безопасности (кто/что/когда/результат), алерты.
10. Процедуры: playbook инцидентов, тест-кейсы и регулярные пентесты/DAST.

5) Аутентификация и управление токенами

OAuth2/OIDC: короткоживущие access-токены, refresh строго по OIDC; audience/issuer/exp проверяются на гейтвее.
JWT: RS256/ES256; минимальный набор клаймов; `nbf/exp/aud` обязательны; запрет на хранение PII. Ротация ключей через JWKS.
DPoP/PoP: привязка токена к ключу клиента для снижения риска replay/угонов.
mTLS для внутренних систем и доверенных партнеров (аттестация по CN/SAN, CRL/OCSP).
HMAC (подписи): детерминированная каноникализация (метод+путь+timestamp+nonce+body-hash); окно допустимого времени (±300s).
Сеансы браузера: SameSite=strict/lax, HttpOnly, Secure; защита от CSRF (double submit/стейт-токены).
Хранилище клиентов: на мобиле — безопасные хранилища (Keychain/Keystore), защита от дебага, пиннинг сертификатов.

6) Авторизация (BOLA-first)

Object-level: каждая операция проверяет право на конкретный ресурс (resource owner / scope / атрибуты).
RBAC/ABAC: роли + атрибуты (страна, сегмент, лимиты риска, KYC-уровень).
Политики: deny-by-default; явные allow; версионирование политик; тесты на негативные кейсы.
Кеш решений: адаптивный TTL + инвалидация при изменении ролей/сегментов.

7) Фильтрация и нормализация запросов (на гейтвее/WAF)

Нормализация: сжатие повторных слэшей, запрет `../`, декодирование один раз, обрезка пробелов/нуль-байтов.
Заголовки: allow-list (`Host`, `Content-Type`, `Accept`, `Authorization`, `Date`, `Idempotency-Key`, нужные trace-заголовки).
Методы: `GET/HEAD` без тела; `POST/PUT/PATCH` — с типом `application/json` или строго разрешенными.
Размеры: max-body, max-headers, max-path; early-reject 413/431.
Файлы: MIME-валидатор, антивирус/сандбокс, запрет активного контента, ресайз/санитайз изображений.
URL-переадресации/фетчи: блок SSRF (deny private ranges/metadata IP, схема только `https`, allow-list доменов).
SQL/NoSQL-паттерны: сигнатуры инъекций через WAF rule-sets + серверная параметризация запросов.

Пример политики заголовков (псевдо-формат)

deny_headers: ["X-Forwarded-Proto","X-Original-URL","Proxy-Connection","Destination"]
require_headers: ["Authorization" (для protected), "Content-Type" (для write)]
strip_duplicates: true max_header_count: 32 max_header_size: 16KB

8) Лимиты, квоты и антибот-защита

Rate limiting: token-bucket/ leaky-bucket; уровни — per IP, per API key, per user, per org.
Quotas: суточные/месячные, отдельные для write/expensive методов.
Адаптивность: динамическое ужесточение при аномалиях (sudden burst/credential stuffing).
Slow-loris/slow-POST: таймауты чтения/keep-alive, ограничение параллельных соединений.
Антибот: device-fingerprint, поведенческие признаки, proof-of-work/капча на повышенный риск, список тор/прокси-сетей.
IP-контроль: гео/ASN-фильтры, deny-листы «грязных» подсетей, allow-листы для партнеров/админ-панели.

9) Валидация входных данных и схем

Fail-closed: все, что не проходит схему — 400. Лишние поля — отклонять.
Типы/диапазоны: числа, даты (UTC/ISO-8601), enum-значения, длины строк, регэкспы.
JSON-качество: max-nesting, запрет больших массивов/ключей, canonical order (опционально).
Бизнес-валидация: идемпотентность по `Idempotency-Key`; анти-фрод-правила (лимиты частоты операций, amount caps).
GraphQL: depth/complexity-лимиты, allow-listed queries, пер-поле авторизация.
gRPC: строгие Protobuf-схемы, обязательные поля, лимиты размера сообщений.

10) Webhooks и внешние вызовы

Подписи: HMAC с таймстампом/nonce; верификация до обработки; окно +/- 5 мин.
Доставка: ретраи с экспоненциальной паузой и джиттером; max-попытки; дедупликация по событийному ID.
IP allow-list поставщика; отдельный поддомен/путь; минимальный хостинг-стек.
Ответы: 2xx только после успешной внутренней записи; иначе 4xx/5xx с понятным кодом.
Исходящий SSRF-контроль: при callback URL — allow-list, запрет приватных адресов.

11) Шифрование и управление секретами

В канале: TLS 1.2+/1.3, пиннинг, строгая политика шифров.
В покое: шифрование БД/объектного хранилища, отдельные ключи для PII/финданных.
KMS/Vault: централизованное хранение секретов, короткие TTL, автоматическая ротация.
Ключи и сертификаты: отдельные для окружений; аудит выдач; запрет вывода в логи.
Token-introspection: offline-списки отзыва (revocation), короткие `exp`.

12) Наблюдаемость, аудит и реагирование

Логи безопасности: попытки/успехи аутентификации, отказы авторизации, rate-limit события, изменения ролей/лимитов.
Трассировка: correlation-ID сквозной; трассинг внешних вызовов.
Метрики: RPS, P95/P99 latency, error-rate по кодам, доля 401/403/429, hit-rate лимитов, аномалии.
Алерты: всплески 401/403/429, рост 5xx, частые idempotency-конфликты, резкие отклонения графQL-complexity.
Playbooks: блокировка ключей/токенов, быстрый откат правил, прогрев deny-листа, уведомление владельцев сервисов.
Форензика: сохранение спорных payload (с безопасным редактированием PII), реплеи на изолированном стенде.

13) Ошибки и ответы клиенту

Единый формат ошибок (код, сообщение, trace-id, категория).
Без утечек: не раскрывать SQL, имена таблиц, внутренние айди; 403 вместо «почему именно нет».
Коды: 400 (валидация), 401 (нет аутентификации), 403 (нет прав), 404 (маскировать существование), 405/406, 413/429, 500/503.
Retry-Hints: для 429 — `Retry-After`; для идемпотентности — совет по повтору с тем же ключом.

14) Архитектурные паттерны

Zero-Trust: mTLS, явная авторизация между всеми сервисами, минимальные привилегии.
API-шлюз + WAF + сервис-меш: разделение обязанностей — периметр, L7-политики, внутренняя аутентификация.
Canary/Blue-Green: выкатывать новые правила фильтрации поэтапно с наблюдением.
Fail-closed: для критических write — лучше безопасно отказать, чем допустить некорректную операцию.
Backpressure: очереди/буферы, circuit breaker, timeouts/budgets.

15) Примеры практических правил (псевдо-конфиг)

15.1 Ограничение путей и методов

/api/v1/payments:
allow_methods: [POST, GET]
auth: oauth2_required body:
content_type: application/json max_size: 256KB

15.2 Идемпотентность

require_header: Idempotency-Key (UUIDv4)
store: redis:ttl=24h on_duplicate: return_previous_result

15.3 Подпись запроса (HMAC)

signature:
scheme: "HMAC-SHA256"
required_headers: ["X-Signature","X-Timestamp","X-Nonce"]
allowed_drift: 300s string_to_sign: METHOD + "\n" + PATH + "\n" + SHA256(body) + "\n" + X-Timestamp + "\n" + X-Nonce

15.4 SSRF-защита

outbound_http:
allowlist_domains: ["kyc. partner. com","psp. example. net"]
block_private_ip: true require_https: true

15.5 GraphQL лимит

graphql:
max_depth: 8 max_complexity: 500 allowlisted_operations_only: true

16) Специфика iGaming/финансов

Сегментные лимиты: зависят от KYC/страны/рискового профиля.
Временные окна: правила частоты депозитов/выводов, «остывание» между транзакциями.
Анти-абьюз бонусов: консистентные блокировки на аккаунт/устройство/IP/платежный инструмент.
Аудит требований регуляторов: хранение логов действий и решений (KYC/AML), ретеншн-периоды, неизменяемые журналы.

17) Контрольный список prod-готовности

• Полный каталог API и карта потоков данных (PII/финансы помечены).
• OpenAPI/Protobuf-схемы, тесты валидации и контракты в CI.
• mTLS/HMAC/OAuth2 настроены; короткие TTL токенов; ротация ключей.
• BOLA-тесты и негативные кейсы авторизации; централизованный PDP.
• Лимиты/квоты/anti-bot, защита от slow-loris; IP-фильтры.
• WAF/гейтвей-правила нормализации, анти-инъекционные сигнатуры.
• Идемпотентность write-операций; защита от replay.
• Webhook-подписи и allow-list; изолированные endpoints.
• Секреты в KMS/Vault; зашифрованные стораджи; алерты на аномалии.
• Дэшборды, алерты, аудит-логи; отработанные playbooks инцидентов.
• Регулярный пентест/DAST/SAST, треки уязвимостей и деплой патчей.

18) Антипаттерны (чего нельзя)

Доверять `X-Forwarded-` без жесткой терминции TLS на своем периметре.
Принимать произвольные `Content-Type` и «мягкие» схемы JSON.
Долгоживущие JWT без отзыва/ротации.
Смешивать роли и бизнес-правила в коде без централизованных политик.
Логи с секретами/PII; детальные 500-сообщения наружу.
«Временные» открытые эндпоинты без лимитов и авторизации.

19) Версионирование и депрекейт

Версии в пути/заголовке; политика поддержки (например, N-2).
Объявления: сроки депрекейта, мониторинг использования старых версий, управляемое отключение.
Совместимость: контракты и тест-матрицы клиентов/партнеров.

20) Тестирование безопасности

Контрактные тесты схем/политик, fuzzing входов, negative auth.
Перфоманс-профили с лимитами/квотами, испытание защит (chaos-трафик).
Red-team/bug-bounty: сценарии BOLA, SSRF, подписи/реплеи, GraphQL-complexity.

TL;DR

1. Каталог API + строгие схемы.
2. OAuth2/OIDC для клиентов, mTLS/HMAC внутри.
3. BOLA-периметр на каждый ресурс (ABAC/RBAC).
4. Фильтрация: нормализация путей/заголовков, лимиты, WAF-правила.
5. Идемпотентность, подписи, защита от replay/SSRF.
6. KMS/Vault и ротация секретов.
7. Наблюдаемость, алерты, playbooks.