Come il casinò controlla la sicurezza delle richieste API

Perché la sicurezza dell'API nel iGaming è critica

API - Sistema nervoso del casinò: scommesse, portafogli, cassa, provider di giochi, KYC/KYT, telemetria. Qualsiasi buco = soldi, PII, licenza, reputazione. A differenza dell'e-commerce convenzionale, il casinò ha caratteristiche: tempo reale, tempo di denaro, regolazione, alta motivazione degli attaccanti e una matrice di integrazione complessa.

Principi architettonici (scheletro di protezione)

1. Zero-Trust & Least Privilege. Non ci fidiamo né della rete né dei clienti. Ogni chiamata viene verificata, la disponibilità è il minimo necessario (RBAC/ABAC).

2. Separazione dei domini. Denaro/PII/biglietteria/gateway di gioco - perimetri e reti differenti, chiavi e politiche diverse.

3. Un unico gateway API. Punto: mTLS, WAF/bot management, OAuth2/JWT, rate limits, threat-feeds, logica.

4. Osservabilità predefinita. Tracing, correlazione «traceId», alert su anomalie (SLO/SIEM).

5. Default sicuro. TTL di TTL brevi, il divieto di CORS «larghi», deny-by-default nel NetworkPolicy.

Autenticazione e autorizzazione

Chiamate tra server: mTLS + JWT (5-10 min) con «aud/iss/kid» e rotazione delle chiavi; Firma del corpo HMAC opzionale.

Chiamate client: OAuth2 (PKCE per cellulari), sessione cookies con "HttpOnly", "SameSite=Lax	Strict`, `Secure`.
Admine/API zapport: SSO + MFA, IP-allowlist, privilegi per soli ruoli.
Pagamenti/operazioni critiche: principio a 4 occhi e passo di conferma.

Integrità chiamata, firme, tempo, idempotenza

Firma HMAC della richiesta di presentazione canonizzata: ordinamento dei parametri, seriatizzazione stabile di JSON (senza spazi, ordine delle chiavi uguale), intestazioni:


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…

Protezione replay: finestra di tempo valida (© 300 secondi), convalida «nonce» nella cache.

Idempotency-Key per denaro/webhoop: la ripetizione della richiesta non crea un secondo debito/prestito.

mTLS al portafoglio/biglietteria/provider: crittografia dei trasporti, controllo reciproco delle parti.

Esempio di POST protetto:


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"
}

Convalida di accesso: schemi e canonizzazioni

La JSON è come un contratto. Ogni stringa è attraverso la convalida di tipi, intervalli e whitelists (ISO di valuta/paese, enum states).

Size limits - Limita le dimensioni del corpo e degli array, impedendo gli allegati «profondi».

Canonizzazione di JSON prima firma/login, schermata speciale, rigoroso'Content-Type '.

Blocca assegnazione di massa - Campi allow-lists espliciti.

Protezione della superficie: WAF, bot, velocità

WAF/bot management: firme e rilevazione comportamentale (rate, geo, device-fingerprint).

Rate limits/quotas: su IP/token/client/metodo; limiti separati per denaro e non-denaro.

DoS/abuse control: circuiti-breakers, timeouts, backpressure, «liste grigie».

KORS: «Access-Control-Allow-Origin», disabilitazione wildcard e «Authorization» nei browser non necessario.

API OWASP Top-10 → azioni specifiche

PALLA/BBLA (Broken Object/Function Level Auth): ABAC per il proprietario della risorsa, filtri per «playerId», proibizione degli identificatori «estranei».

Interrogazioni parametrate, inattività degli URL esterni nelle chiamate server, allowlist host.

Excessive Data Exposure: speiping delle risposte (fields mask), paginazione, normalizzazione degli errori senza perdita di parti.

Sicurezza Misconfigurazione: combinazione di versioni TLS/Cifrature, titoli CSP/Permissioni-Policy/Referrer-Policy.

Unsafe Consumation of APIs: avvolgimenti sopra le API di provider con timeout, retrai, deduplicazione.

PII e privacy

Tornizzazione e crittografia PII (attributi del giocatore, documenti KYC): KMS/HSM, campi - AES-GCM.

Data minimization: gli eventi/login sono solo alias ('playerId'), mai i numeri di documento/mappa.

Retention: TTL diverso per domini (portafogli/giochi/biglietteria) secondo i requisiti giurisdizionali.

Accesso a ruoli: separa la lettura di PII a livello di database e servizi (row-level security/policy).

Webhoop e biglietteria sicuri

Controllo a due fattori: mTLS alla firma web + HMAC del provider.

Anti-replay: X-Idempotency-Key, X-Timestamp, finestra dell'ora.

Allowlist IP/ASN provider, egress-IP statici in uscita da noi.

«Velenosi» payloads - Limiti di quota, ignora campi inutilizzati, schema rigoroso.

Controllo e test endpoint: cassetta di sabbia provider + test contrattuali.

Segreti e chiavi

Storage: KMS/HSM/Secret Manager, mai in git/variabili di ambiente senza crittografia.

Rotazione: automatico, «kid» nelle intestazioni/metadati, ritiro delle chiavi compromesse.

Accesso: break-glass procedure, registrazione di tutti gli accessi ai segreti.

Loghi, roulotte, alert

La correlazione è " " in ogni strato (ingress "API).

Anomalie: «401/403/429», «VOID», «bet». reject per regione, insicurezza.

I segnali di attacco sono molti «nonce», tentativi antichi «timestamp», corpi lunghi, «kid» sconosciuti.

Archivio dei logi: invariato (WORM), area di accesso separata, maschera PII.

Test-piano e controllo qualità

Static/Dynamic AppSec: SAST/DAST su ogni CI, firme di segreti, dipendenze - SCA.

Pentesti e Red Tim: script replay, firma su un canale sbagliato, aggiramento rate-limits, PALLA, SSRF.

Test contrattuali, «negative case».

Chaos/latency drills - comportamento nei timeout dei provider/biglietteria, idampotenza corretta.

Bug-bounty è un programma con perimetro e regole di reportage separati.

Intestazioni e impostazioni utili

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

`Content-Security-Policy: default-src 'none'; frame-ancestor'none '(per domini API)

`Referrer-Policy: no-referrer`

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

`X-Content-Type-Options: nosniff`

«Cache-Control: no-store» sugli endpoint privati

Risposte di errore: formato unico

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

Anti-pattern (che rompe la sicurezza)

Token JWT/refresh a lunga vita senza rotazione o riferimento al dispositivo.

La firma «com'è», senza la canonizzazione della JSON, è un collegamento di controllo.

L'assenza dì Idempotency-Key "sui soldi/webhoot ha → i doppi pagamenti.

Wildcard-CORS e «in Access-Control-Allow-Origin» per gli endpoint con «Authorization».

Loghi PII/segreti, condivisione dei reparti «per tutti».

Chiave comune unica HMAC per tutte le integrazioni.

Non ci sono limiti per la dimensione/profondità di JSON, non ci sono timeout e circuiti-breakers.

Errori che rivelano le parti interne (stack traces, SQL, versioni librerie).

Assegno di sicurezza API casinò

Perimetro e trasporti

mTLS su canali interserver e provider; TLS 1. 3 dappertutto.
gateway API con gestione WAF/bot, rate limiting, threat-feeds.
CORS - Solo indirizzi, senza wildcard.

Autenticazione/autorizzazione

per i clienti, JWT con TTL da 10 min, rotazione delle chiavi ('kid').
RBAC/ABAC per domini; admine - SSO + MFA + IP-allowlist.

Integrità e ripetizione

Firma HMAC, «X-Sollest-Timestamp», «X-Sollest-Nonce» e finestra dell'ora.
'X-Idempotency-Key', su denaro, webhoop, cassa; memorizzazione delle chiavi nella cache.

Convalida

OpenAPI/JSON-Schema, canonizzazione JSON, limiti di dimensioni/profondità.
Mascheraggio e whitelists per i campi proibizione mass assignment.

PII e dati

Tokenizzazione/crittografia PII (KMS/HSM), minimizzazione, criteri di reticenza separati.
Storage diviso per PII/telemetria/denaro.

Integrazioni

Webhook: mTLS+HMAC, allowlist IP, anti-replay, test contrattuali.
Cassa/crittografia: due provider e chiavi/reti diverse, idempotency per accesso/uscita.

Osservabilità

"Tracing con" traceId/playerId/roundId ", allertati per i segnali di attacchi.

Logi invariati (WORM), senza PII/segreti.

Processi

SAST/DAST/SCA in CI, pentest/red tim regolarmente, bug-bounty.
Incidenti runbooks: chiavi revoke, ritorno, comunicazioni.

La sicurezza dell'API non è «mettere WAF». Questo è il sistema: mTLS + firme + idampotenza, rigorosa validazione e canonizzazione, protezione del perimetro e della velocità, isolamento del PII, sicurezza della cassa web, osservabilità e controlli regolari. Facendo parte della cultura ingegneristica, si protegge il denaro, i giocatori e la licenza, mantenendo al contempo la velocità del prodotto e la stabilità dei rilasci.