Як казино стежить за безпекою 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, безпечні вебхуки каси, спостережуваність і регулярні перевірки. Зробивши це частиною інженерної культури, ви захищаєте гроші, гравців і ліцензію, зберігаючи при цьому швидкість продукту і стабільність релізів.