Cum monitorizează cazinoul securitatea cererilor API

De ce securitatea API este esențială în iGaming

API - sistem nervos cazinou: pariuri, portofel, casierie, furnizori de jocuri, KYC/KYT, telemetrie. Orice gaură = bani, PII, licență, reputație. Spre deosebire de comerțul electronic obișnuit, cazinourile au caracteristici: bani în timp real, reglementare, motivația ridicată a atacatorilor și o matrice complexă de integrare.

Principii arhitecturale (schelet de protecție)

1. Zero-Trust și cel mai mic privilegiu. Nu avem încredere în rețea sau clienți. Fiecare apel este verificat, accesele sunt minime necesare (RBAC/ABAC).

2. Separarea domeniului. Bani/PII/cash/gateway-uri de joc - diferite perimetre și rețele, chei și politici diferite.

3. O singură poartă API. Punct: mTLS, WAF/bot management, OAuth2/JWT, limite de rată, amenințare-feed-uri, logare.

4. Observabilitate implicită. Urmărirea, corelarea "traceId', alerte privind anomalii (SLO/SIEM).

5. Valori implicite sigure. Jetoane TTL scurte, interzicerea CORS „wide”, negarea implicită în NetworkPolicy.

Autentificare și autorizare

Apeluri inter-service: mTLS + JWT de scurtă durată (5-10 min) cu „aud/iss/kid” și rotație cheie; semnătură corporală HMAC opţională.

Apeluri client: OAuth2 (PKCE pentru telefoane mobile), cookie-uri de sesiune cu 'HttpOnly', 'SameSite = Lax	Strict ',' Secure '.
Admin/suport API: SSO + MFA, IP-allowlist, privilegii - numai prin roluri.
Plăți/operațiuni critice: principiul 4-ochi și etapa de confirmare.

Integritatea apelurilor - semnături, timp, idempotență

Semnătura HMAC a cererii de depunere canonizată: sortarea parametrilor, serializarea JSON stabilă (fără spații inutile, aceeași ordine cheie), antete:


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

Protecție la reluare: fereastră de timp valabilă (± 300 secunde), verificare 'nonce' în memoria cache.

Idempotency-Key pentru bani/webhook-uri: repetarea cererii nu creează un al doilea debit/credit.

mTLS la portofel/casierie/furnizori: criptarea transportului + verificarea reciprocă a părților.

Exemplu de POST securizat:


POST/portofel/debit
Tip de conținut: aplicație/json
X-Request-Timestamp: 2025-10-17T14:22:05Z
X-Cerere-Nonce: 8c1c0cfa
X-Idempotency-cheie: 9a7f-2b1c
X-Request-Signature: v1 = HMAC-SHA256: Z2V... = =
{
„playerId':” p _ 123 „,” cantitate „:” 10. 00”, „monedă”:” EUR”, „motiv”:” pariu. locul „,” roundId': „R-2025-10-17-PRAGM-12”
}

Validarea intrărilor: scheme și canonicalizare

JSON Schema/OpenAPI ca contract. Orice șir - prin validarea tipurilor, intervalelor și listelor albe (coduri ISO de valute/țări, stări enum).

Limitele de dimensiune: limitați dimensiunea corpului și a matricelor, interziceți cuiburile „adânci”.

Canonicalizarea JSON înainte de semnătură/jurnale, ecranizarea caracterelor speciale, strict „Tip de conținut”.

Sarcină de blocare în masă-liste de permise explicite de câmpuri.

Protecția suprafeței: WAF, boți, viteză

Gestionarea WAF/bot: semnături și detectare comportamentală (rată, geo, amprentă-dispozitiv).

Limite/cote de rată: prin IP/token/client/metodă; limite separate pentru bani și non-bani.

DoS/abuz-control: întrerupătoare de circuit, timeout, backpressure, „liste gri”.

CORS: punct „Access-Control-Allow-Origin”, interdicție wildcard și „Autorizare” în originile încrucișate ale browserului inutil.

OWASP API Top-10 → măsuri specifice

BOLA/BFLA (Broken Object/Function Level Auth): ABAC by resource owner, filtre by 'playerId', interzicerea identificatorilor „straini”.

Injecție/SSRF: cereri parametrizate, interzicerea URL-urilor externe în apelurile serverului, lista de permise a gazdei.

Expunerea excesivă a datelor: modelarea răspunsurilor (masca câmpurilor), paginația, normalizarea erorilor fără scurgerea părților.

Securitate configurare greșită: TLS/cifru versiune unitate, CSP/Permissions-Policy/Referrer-Policy anteturi.

Consumul nesigur de API-uri: ambalaje peste API-uri furnizor cu timeout-uri, retraiuri, eliminare a duplicatelor.

PII și confidențialitate

Tokenizarea și criptarea PII (atribute ale jucătorului, documente KYC): KMS/HSM, câmpuri - AES-GCM.

Minimizarea datelor: în evenimente/jurnale - numai pseudonime ('playerId'), niciodată - numere de document/card.

Retentie: TTL este diferit pentru domenii (portofel/jocuri/casa de marcat) in functie de cerintele jurisdictiilor.

Accesul la rol: diferențierea citirii PII la nivelul bazei de date și al serviciilor (securitate/politică la nivel de rând).

Carti web sigure si box office

Verificarea cu doi factori: mTLS la webhook + semnătura HMAC a furnizorului.

Anti-reluare: 'X-Idempotency-Key', 'X-Timestamp', fereastra de timp.

Allowlist IP/ASN furnizor, static ieșire-IP cu noi.

Sarcini utile „otrăvitoare”: limite de dimensiune, ignorarea câmpurilor neutilizate, schemă strictă.

Criteriu final de audit și de testare: furnizor sandbox + teste contractuale.

Secrete și chei

Stocare: KMS/HSM/Secrets-manager, niciodată în variabile git/mediu fără criptare.

Rotație: automat, „copil” în anteturi/metadate, revocarea cheilor compromise.

Acces: proceduri de spargere a sticlei, logare toate accesul la secrete.

Busteni, trasee, alerte

Corelație: 'traceId/requestId/playerId/roundId' în fiecare strat (intrare → API → furnizor de → portofel → webhook).

Anomalii: supratensiune '401/403/429', creştere 'VOID', salturi 'bet. respinge' pe regiuni, eşecuri HMAC/mTLS.

Semnale de atac: multe 'nonce' reluări, vechi 'timestamp' attempts, corpuri lungi, necunoscut 'copil'.

Stocare jurnal: imuabil (WORM), zonă de acces separată, PII mascare.

Planul de testare și controlul calității

Static/Dynamic AppSec: SAST/DAST pe fiecare CI, semnături secrete, dependențe - SCA.

Pentests și ed-tim: scripturi de reluare, semnătură pe canalul greșit, by-pass rate-limite, BOLA, SSRF.

Teste contractuale: pentru OpenAPI/JSON-Schema, „cazuri negative”.

Exerciții de haos/latență: comportament la termenele furnizorilor/caselor de marcat, corectitudinea idempotenței.

Bug-bounty: un program cu un perimetru separat și reguli de raportare.

Titluri și setări utile

'Strict-Transport-Securitate: max-age = 63072000; includeSubDomenii; preîncărcare "

"Content-Security-Policy: default-src" none "; frame-strămoșii „none” (pentru domeniile API)

„Politica de trimitere: fără trimitere”

'Permissions-Policy: geolocation = (), microfon = (), camera = ()'

„X-Content-Type-Options: nosniff”

'Cache-Control: no-store' pe criterii finale private

Răspunsuri de eroare - Format unic

json
{„eroare”: „INVALID _ SIGNATURE”, „cod”: „SEC _ 401”, „traceId':” tr _ 5f1 „,” ts': „2025-10-17T14: 22: 06Z”}

Anti-modele (care sparge securitatea)

Jetoane JWT/refresh cu durată lungă de viață fără rotație și legare la dispozitiv.

Semnătura „așa cum este” fără canonicalizarea JSON → trecerea verificărilor.

Lipsa de „Idempotency-Key” pe bani/webhook-uri → dublu write-off-uri.

Wildcard-CORS și "în" Access-Control-Allow-Origin "pentru punctele finale cu" Autorizare ".

Jurnale cu PII/secrete, acces partajat la jurnalele „pentru toată lumea”.

O singură cheie partajată HMAC pentru toate integrările.

Fără limite de dimensiune/adâncime JSON, fără întreruperi de timp și întrerupătoare de circuit.

Erori care dezvăluie piese interne (urme de stivă, SQL, versiuni de bibliotecă).

Lista de verificare a securității API Casino

Perimetru și transport

mTLS pe canalele inter-servicii și furnizori; TLS 1. 3 peste tot.
API gateway cu WAF/bot management, limitarea ratei, amenințare-feed-uri.
CORS - numai adresabil, nici un wildcard.

Autentificare/Autorizare

OAuth2/OpenID pentru clienți, JWT cu TTL ≤ 10 min, rotație cheie ('kid').
RBAC/ABAC pe domenii; admin - SSO + MFA + IP-allowlist.

Integritate și reevaluări

Semnătura HMAC, „X-Request-Timestamp”, „X-Request-Nonce” și fereastra de timp.
„X-Idempotency-Key” pe bani, carti web, checkout; stocarea cheilor în memoria cache.

Validare

OpenAPI/JSON-Schema, canonicalizarea JSON, limitele de dimensiune/adâncime.
Mascarea și listele albe pentru câmpuri; interzicerea repartizării în masă.

PII și date

tokenizare/criptare PII (KMS/HSM), minimizare, politici de retenție separate.
Split de stocare pentru PII/telemetrie/bani.

Integrare

Webhooks: mTLS + HMAC, IP allowlist, anti-reluare, teste de contract.
Numerar/cripto: doi furnizori și chei/rețele diferite, idempotență pentru intrare/ieșire.

Observabilitate

Urmărirea cu 'traceId/playerId/roundId', alertă la semnalele de atac.
Jurnale imuabile (WORM), fără PII/secrete.

Procese

SAST/DAST/SCA în CI, pentestes/ed-tim în mod regulat, bug-recompensă.
Runbooks incidente: revoca chei, rollback, comunicații.

API de securitate în iGaming nu este "pune WAF. "Acestea sunt sistemul: mTLS + semnături + idempotență, validare strictă și canonicalizare, perimetrul și protecția vitezei, izolare PII, case de marcat sigure, observabilitate și verificări regulate. Făcând parte din cultura ingineriei, protejați banii, jucătorii și licența menținând în același timp viteza produsului și stabilitatea eliberării.