Как казино следит за безопасностью API-запросов

Почему безопасность API в iGaming критична

API — нервная система казино: ставки, кошелёк, касса, провайдеры игр, KYC/KYT, телеметрия. Любая дырка = деньги, PII, лицензия, репутация. В отличие от обычных e-commerce, у казино есть особенности: реальное-время денег, регуляторика, высокая мотивация атакующих и сложная интеграционная матрица.

Архитектурные принципы («скелет» защиты)

1. Zero-Trust & Least Privilege. Не доверяем ни сети, ни клиентам. Каждый вызов проверяется, доступы — минимально необходимые (RBAC/ABAC).

2. Разделение доменов. Деньги/PII/касса/игровые шлюзы — разные периметры и сети, разные ключи и политики.

3. Единый API-шлюз. Точка: mTLS, WAF/бот-менеджмент, OAuth2/JWT, rate limits, threat-feeds, логирование.

4. Наблюдаемость по умолчанию. Трейсинг, корреляция `traceId`, алерты на аномалии (SLO/SIEM).

5. Безопасные дефолты. Короткие TTL токенов, запрет «широких» CORS, deny-by-default в NetworkPolicy.

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

Межсервисные вызовы: mTLS + короткоживущие JWT (5–10 мин) с `aud/iss/kid` и ротацией ключей; опционально HMAC-подпись тела.

Клиентские вызовы: OAuth2 (PKCE для мобилок), session cookies с `HttpOnly`, `SameSite=Lax	Strict`, `Secure`.
Админ/API саппорта: SSO + MFA, IP-allowlist, привилегии — только по ролям.
Выплаты/критичные операции: 4-глазный принцип и шаг подтверждения.

Целостность вызова: подписи, время, идемпотентность

HMAC-подпись запроса по канонизированному представлению: сортировка параметров, стабильная сериализация JSON (без лишних пробелов, одинаковый порядок ключей), заголовки:


X-Request-Timestamp: 2025-10-17T14:22:05Z
X-Request-Nonce: 8c1c...fa
X-Request-Signature: v1=HMAC-SHA256:base64(…)
X-Idempotency-Key: c0a4-77f…

Replay-защита: допустимое окно времени (±300 сек), проверка `nonce` в кэше.

Idempotency-Key для денег/вебхуков: повтор запроса не создаёт второй дебет/кредит.

mTLS к кошельку/кассе/провайдерам: шифрование транспорта + взаимная проверка сторон.

Пример защищённого POST:


POST /wallet/debit
Content-Type: application/json
X-Request-Timestamp: 2025-10-17T14:22:05Z
X-Request-Nonce: 8c1c0cfa
X-Idempotency-Key: 9a7f-2b1c
X-Request-Signature: v1=HMAC-SHA256:Z2V…==
{
"playerId":"p_123",  "amount":"10.00",  "currency":"EUR",  "reason":"bet.place",  "roundId":"R-2025-10-17-PRAGM-12"
}

Валидация входа: схемы и каноникализация

JSON Schema/OpenAPI как контракт. Любая строка — через валидацию типов, диапазонов и whitelists (ISO-коды валют/стран, enum статусов).

Size limits: ограничение размера тела и массивов, запрет «глубоких» вложенностей.

Каноникализация JSON перед подписью/логами, экранирование спецсимволов, строгий `Content-Type`.

Блокировка массового присвоения (mass assignment): явные allow-lists полей.

Защита поверхности: WAF, боты, скорость

WAF/бот-менеджмент: сигнатуры и поведенческое выявление (rate, гео, device-fingerprint).

Rate limits/quotas: по IP/токену/клиенту/методу; отдельные лимиты на деньги и не-деньги.

DoS/abuse-контроль: circuit-breakers, timeouts, backpressure, «серые списки».

CORS: точечные `Access-Control-Allow-Origin`, запрет wildcard и `Authorization` в браузерных кросс-ориджин без нужды.

OWASP API Top-10 → конкретные меры

BOLA/BFLA (Broken Object/Function Level Auth): ABAC по владельцу ресурса, фильтры по `playerId`, запрет «чужих» идентификаторов.

Injection/SSRF: параметризованные запросы, запрет внешних URL в серверных вызовах, allowlist хостов.

Excessive Data Exposure: шейпинг ответов (fields mask), пагинация, нормализация ошибок без утечки деталей.

Security Misconfiguration: единство версий TLS/шифров, заголовки CSP/Permissions-Policy/Referrer-Policy.

Unsafe Consumption of APIs: обёртки над провайдерскими API с таймаутами, ретраями, дедупликацией.

PII и приватность

Токенизация и шифрование PII (атрибуты игрока, документы KYC): KMS/HSM, поля — AES-GCM.

Data minimization: в события/логи — только псевдонимы (`playerId`), никогда — номера документов/карт.

Retention: TTL разный для доменов (кошелёк/игры/касса) согласно требованиям юрисдикций.

Доступ по ролям: разграничение чтения PII на уровне БД и сервисов (row-level security/политики).

Безопасные вебхуки и касса

Двухфакторная проверка: mTLS к вебхуку + HMAC-подпись провайдера.

Anti-replay: `X-Idempotency-Key`, `X-Timestamp`, окно времени.

Allowlist IP/ASN провайдера, статические исходящие egress-IP у нас.

«Ядовитые» payloads: лимиты размеров, игнор неиспользуемых полей, строгая схема.

Аудит и тест-эндпоинт: песочница провайдера + контрактные тесты.

Секреты и ключи

Хранение: KMS/HSM/Secrets-manager, никогда не в git/переменных окружения без шифрования.

Ротация: автоматическая, `kid` в заголовках/метаданных, отозвание компрометированных ключей.

Доступ: break-glass процедуры, журналирование всех обращений к секретам.

Логи, трейсы, алёрты

Корреляция: `traceId/requestId/playerId/roundId` в каждом слое (ingress → API → кошелёк → провайдер → вебхук).

Аномалии: всплеск `401/403/429`, рост `VOID`, скачки `bet.reject` по регионам, неуспехи HMAC/mTLS.

Сигналы атаки: много `nonce`-повторов, попытки старых `timestamp`, длинные тела, неизвестные `kid`.

Хранилище логов: неизменяемое (WORM), отдельная зона доступа, маскирование PII.

Тест-план и контроль качества

Static/Dynamic AppSec: SAST/DAST на каждом CI, сигнатуры секретов, зависимостям — SCA.

Пентесты и ред-тим: сценарии replay, подпись на неверном канале, обход rate-limits, BOLA, SSRF.

Контрактные тесты: на OpenAPI/JSON-Schema, «negative cases».

Chaos/latency drills: поведение при таймаутах провайдеров/кассы, корректность идемпотентности.

Bug-bounty: программа с отдельным периметром и правилами репортинга.

Полезные заголовки и настройки

`Strict-Transport-Security: max-age=63072000; includeSubDomains; preload`

`Content-Security-Policy: default-src 'none'; frame-ancestors 'none'` (для API-доменов)

`Referrer-Policy: no-referrer`

`Permissions-Policy: geolocation=(), microphone=(), camera=()`

`X-Content-Type-Options: nosniff`

`Cache-Control: no-store` на приватных эндпоинтах

Ответы об ошибках: единый формат

json
{ "error":"INVALID_SIGNATURE", "code":"SEC_401", "traceId":"tr_5f1", "ts":"2025-10-17T14:22:06Z" }

Анти-паттерны (что ломает безопасность)

Долгоживущие JWT/refresh-токены без ротации и привязки к устройству.

Подпись «как есть» без каноникализации JSON → разъезд проверок.

Отсутствие `Idempotency-Key` на деньгах/вебхуках → двойные списания.

Wildcard-CORS и `` в `Access-Control-Allow-Origin` для эндпоинтов с `Authorization`.

Логи с PII/секретами, общий доступ к логам «для всех».

Единый общий ключ HMAC для всех интеграций.

Нет лимитов на размер/глубину JSON, нет таймаутов и circuit-breakers.

Ошибки, раскрывающие внутренние детали (stack traces, SQL, версии библиотек).

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

Периметр и транспорт

mTLS на межсервисных и провайдерских каналах; TLS 1.3 везде.
API-шлюз с WAF/бот-менеджментом, rate limiting, threat-feeds.
CORS — только адресные, без wildcard.

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

OAuth2/OpenID для клиентов, JWT с TTL ≤ 10 мин, ротация ключей (`kid`).
RBAC/ABAC по доменам; админ — SSO+MFA+IP-allowlist.

Целостность и повторные запросы

HMAC-подпись, `X-Request-Timestamp`, `X-Request-Nonce` и окно времени.
`X-Idempotency-Key` на деньгах, вебхуках, кассе; хранение ключей в кэше.

Валидация

OpenAPI/JSON-Schema, каноникализация JSON, лимиты размеров/глубины.
Маскирование и whitelists для полей; запрет mass assignment.

PII и данные

Токенизация/шифрование PII (KMS/HSM), минимизация, отдельные политики ретенции.
Разделённые хранилища для PII/телеметрии/денег.

Интеграции

Вебхуки: mTLS+HMAC, allowlist IP, анти-replay, контрактные тесты.
Касса/крипта: два провайдера и разные ключи/сети, idempotency на вход/выход.

Наблюдаемость

Трейсинг с `traceId/playerId/roundId`, алёрты на сигналы атак.
Логи неизменяемые (WORM), без PII/секретов.

Процессы

SAST/DAST/SCA в CI, пентесты/ред-тим регулярно, bug-bounty.
Runbooks инцидентов: revoke ключей, откат, коммуникации.

Безопасность API в iGaming — это не «ставить WAF». Это система: mTLS+подписи+идемпотентность, строгая валидация и каноникализация, защита периметра и скоростей, изоляция PII, безопасные вебхуки кассы, наблюдаемость и регулярные проверки. Сделав это частью инженерной культуры, вы защищаете деньги, игроков и лицензию, сохраняя при этом скорость продукта и стабильность релизов.