Comment le casino surveille la sécurité des requêtes API

Pourquoi la sécurité de l'API dans iGaming est critique

L'API est le système nerveux du casino : paris, portefeuille, caisse, fournisseurs de jeux, KYC/KYT, télémétrie. N'importe quel trou = argent, PII, licence, réputation. Contrairement à l'e-commerce conventionnel, le casino a des caractéristiques : temps réel de l'argent, la réglementation, la motivation élevée des attaquants et une matrice d'intégration complexe.

Principes architecturaux (« squelette » de protection)

1. Zero-Trust & Least Privilege. Nous ne faisons pas confiance au réseau ou aux clients. Chaque appel est validé, les accès sont minimes (RBAC/ABAC).

2. Séparation des domaines. L'argent/PII/caisse/jeux passerelles - différents périmètres et réseaux, différentes clés et politiques.

3. Une seule passerelle API. Point : mTLS, WAF/bot management, OAuth2/JWT, rate limites, threat-feeds, loging.

4. L'observabilité par défaut. Tracing, corrélation 'traceId', alertes sur les anomalies (SLO/SIEM).

5. Des défauts de sécurité. Tokens TTL courts, interdiction des CORS « larges », deny-by-default dans NetworkPolicy.

Authentification et autorisation

Appels interservices : mTLS + JWT à courte durée de vie (5-10 min) avec 'aud/iss/kid' et rotation des clés ; en option la signature HMAC du corps.

Appels client : OAuth2 (PKCE pour Mobile), cookies de session avec 'HttpOnly', 'SameSite = Lax	Strict`, `Secure`.
Admin/API sapport : SSO + MFA, IP-allowlist, privilèges - uniquement par rôle.
Paiements/opérations critiques : principe à 4 yeux et étape de confirmation.

Intégrité de l'appel : signatures, heure, idempotence

Signature HMAC de la demande par représentation canonisée : tri des paramètres, sérialisation JSON stable (pas d'espaces superflus, même ordre de clés), titres :


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-Protection : Fenêtre temporelle valide (± 300 secondes), vérification 'nonce' dans le cache.

Idempotency-Key pour l'argent/webhooks : la répétition d'une requête ne crée pas de deuxième débit/crédit.

mTLS au portefeuille/caisse/fournisseurs : cryptage des transports + vérification mutuelle des parties.

Exemple de POST sécurisé :


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

Validation d'entrée : schémas et canonisation

JSON Schema/OpenAPI en tant que contrat. Toute chaîne est via la validation des types, des gammes et des whitelists (codes ISO des monnaies/pays, enum des statuts).

Limites de taille : limitation de la taille du corps et des matrices, interdiction des imbrications « profondes ».

Canonisation JSON avant signature/logs, blindage des simulateurs spéciaux, strict « Content-Type ».

Blocage de l'affectation de masse (mass assignment) : allow-lists explicites des champs.

Protection de surface : WAF, bots, vitesse

WAF/bot management : signatures et identification comportementale (rate, geo, device-fingerprint).

Taux limites/quotes : par IP/token/client/méthode ; des limites séparées pour l'argent et le non-argent.

DoS/abuse control : circuits-breakers, timeouts, backpressure, « listes grises ».

CORS : point 'Access-Control-Allow-Origin', interdiction de wildcard et 'autorisation'dans le navigateur cross-origin sans besoin.

OWASP API Top-10 → mesures spécifiques

BOLA/BFLA (Broken Object/Function Level Auth) : ABAC par propriétaire de la ressource, filtres par 'playerId', interdiction des identifiants « étrangers ».

Injection/SSRF : requêtes paramétrées, interdiction des URL externes dans les appels de serveur, liste d'hôtes.

Excessive Data Exposure : shaping des réponses (fields mask), pagination, normalisation des erreurs sans fuite de pièces.

Sécurité Misconfiguration : unité des versions TLS/cryptage, en-têtes CSP/Permissions-Policy/Referrer-Policy.

Unsafe Consumption of APIs : enveloppes au-dessus des API de fournisseur avec temporisation, retraits, déduplication.

PII et la vie privée

Tokenization et cryptage PII (attributs du joueur, documents KYC) : KMS/HSM, champs - AES-GCM.

Minimisation des données : dans les événements/logs, seuls les alias ("playerId'), jamais les numéros de documents/cartes.

Retraite : TTL différent pour les domaines (portefeuille/jeux/caisse) selon les exigences des juridictions.

Accès par rôle : délimitation de la lecture PII au niveau de la base de données et des services (row-level security/policy).

Webhooks et caisse sécurisés

Vérification à deux facteurs : mTLS au webhook + signature HMAC du fournisseur.

Anti-replay : 'X-Idempotency-Key', 'X-Timestamp', fenêtre temporelle.

Allowlist IP/ASN du fournisseur, egress-IP statique sortant chez nous.

Payloads « toxiques » : limites de taille, ignorer les champs inutilisés, schéma strict.

Audit et endpoint test : bac à sable fournisseur + tests contractuels.

Secrets et clés

Stockage : KMS/HSM/Secret-Manager, jamais en git/variables d'environnement sans chiffrement.

Rotation : automatique, 'kid' dans les titres/métadonnées, révocation des clés compromises.

Accès : procédures break-glass, journalisation de tous les appels aux secrets.

Logs, remorques, alertes

Corrélation : 'traceId/requestId/playerId/roundId' dans chaque couche (ingress → API → portefeuille → fournisseur → webhook).

Anomalies : sursaut de '401/403/429', croissance de 'VOID', surtensions de 'bet. reject 'par région, échecs HMAC/mTLS.

Signaux d'attaque : beaucoup de 'nonce' -venteurs, tentatives de vieux 'timestamp', corps longs, inconnus 'kid'.

Stockage de logs : immuable (WORM), zone d'accès séparée, masquage PII.

Plan d'essai et contrôle qualité

Statique/Dynamic AppSec : SAST/DAST sur chaque CI, signatures de secrets, dépendances - SCA.

Pentestes et red tim : scripts replay, signature sur un canal incorrect, contournement des limites de taux, BOLA, SSRF.

Tests contractuels : sur OpenAPI/JSON-Schema, « negative cases ».

Chaos/latency drills : comportement dans les délais des fournisseurs/caisses, exactitude de l'idempotence.

Bug-bounty : un programme avec un périmètre séparé et des règles de reporting.

Titres et paramètres utiles

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

`Content-Security-Policy: default-src 'none'; frame-ancestors 'none "(pour les domaines API)

`Referrer-Policy: no-referrer`

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

`X-Content-Type-Options: nosniff`

« Cache-Control : no-store » sur les endpoints privés

Réponses d'erreur : format unique

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

Anti-modèles (qui brise la sécurité)

Jetons JWT/refresh à longue durée de vie sans rotation ni liaison à l'appareil.

Signature « telle quelle » sans canonisation JSON → séparation des contrôles.

L'absence de 'Idempotency-Key' sur l'argent/les webhooks → les doubles débits.

Wildcard-CORS et « dans Access-Control-Allow-Origin » pour les endpoints avec « Autorisation ».

Logs avec PII/secrets, partage de logs « pour tous ».

Clé commune HMAC unique pour toutes les intégrations.

Il n'y a pas de limite de taille/profondeur JSON, pas de temporisateurs et de breakers de circuit.

Erreurs qui révèlent les détails internes (stack traces, SQL, versions des bibliothèques).

Chèque de sécurité API Casino

Périmètre et transport

mTLS sur les canaux interservices et fournisseurs ; TLS 1. 3 partout.
passerelle API avec WAF/bot management, rate limiting, threat-feeds.
CORS - adresse uniquement, sans wildcard.

Authentification/autorisation

OAuth2/OpenID pour les clients, JWT avec TTL ≤ 10 min, rotation des clés ('kid').
RBAC/ABAC par domaine ; admin - SSO + MFA + IP-allowlist.

Intégrité et demandes répétées

Signature HMAC, « X-Request-Timestamp », « X-Request-Nonce » et fenêtre temporelle.
« X-Idempotency-Key » sur l'argent, les webhooks, la caisse ; stockage des clés dans le cache.

Validation

OpenAPI/JSON-Schema, canonisation JSON, limites de taille/profondeur.
Masquage et whitelists pour les champs ; interdiction de la masse.

PII et données

Tokenization/cryptage PII (KMS/HSM), minimisation, politiques de rétractation séparées.
Stockage séparé pour PII/télémétrie/argent.

Intégration

Webhooks : mTLS + HMAC, IP allowlist, anti-replay, tests contractuels.
Caisse/cryptage : deux fournisseurs et des clés/réseaux différents, idempotency par entrée/sortie.

Observabilité

Tracing avec 'traceId/playerId/roundId', alertes sur les signaux d'attaque.
Logs immuables (WORM), sans PII/secrets.

Processus

SAST/DAST/SCA dans CI, pentestes/red tim régulièrement, bug-bounty.
Runbooks incidents : clés revoke, retour en arrière, communications.

La sécurité de l'API dans iGaming n'est pas « parier WAF ». C'est le système : mTLS + signatures + idempotence, validation et canonisation rigoureuses, protection du périmètre et des vitesses, isolation PII, webhooks sécurisés de la caisse, observabilité et contrôles réguliers. En faisant partie de la culture de l'ingénierie, vous protégez l'argent, les joueurs et la licence, tout en maintenant la vitesse du produit et la stabilité des sorties.