Wie das Casino die Sicherheit von API-Anfragen überwacht

Warum die API-Sicherheit in iGaming kritisch ist

API - Nervensystem des Casinos: Wetten, Geldbörse, Kasse, Spieleanbieter, KYC/KYT, Telemetrie. Jedes Loch = Geld, PII, Lizenz, Reputation. Im Gegensatz zum herkömmlichen E-Commerce hat das Casino Merkmale: Echtzeit-Geld, Regulatoren, hohe Motivation der Angreifer und eine komplexe Integrationsmatrix.

Architekturprinzipien („Skelett“ des Schutzes)

1. Zero-Trust & Least Privilege. Wir vertrauen weder dem Netzwerk noch den Kunden. Jeder Anruf wird überprüft, die Zugriffe sind minimal notwendig (RBAC/ABAC).

2. Domänentrennung. Geld/PII/Kasse/Spielgateways - verschiedene Perimeter und Netzwerke, verschiedene Schlüssel und Richtlinien.

3. Ein einziges API-Gateway. Punkt: mTLS, WAF/Bot-Management, OAuth2/JWT, Ratenlimits, Threat-Feeds, Protokollierung.

4. Standardbeobachtbarkeit. Tracing, Korrelation 'traceId', Warnungen auf Anomalien (SLO/SIEM).

5. Sichere Ausfälle. Kurze TTL-Token, Verbot von „breiten“ CORS, deny-by-default in NetworkPolicy.

Authentifizierung und Autorisierung

Dienstübergreifende Anrufe: mTLS + kurzlebige JWTs (5-10 min) mit 'aud/iss/kid' und Schlüsselrotation; optional HMAC-Signatur des Körpers.

Kundenaufrufe: OAuth2 (PKCE für Mobilgeräte), Session-Cookies mit 'HttpOnly', 'SameSite = Lax	Strict`, `Secure`.
Sapport Admin/API: SSO + MFA, IP-allowlist, Privilegien - nur für Rollen.
Auszahlungen/kritische Operationen: 4-Augen-Prinzip und Bestätigungsschritt.

Anrufintegrität: Signaturen, Zeit, Idempotenz

HMAC-Signatur der Anfrage nach kanonisierter Darstellung: Parametersortierung, stabile JSON Serialisierung (keine unnötigen Leerzeichen, gleiche Schlüsselreihenfolge), Header:


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-Schutz: gültiges Zeitfenster (± 300 Sek.), Prüfung 'nonce' im Cache.

Idempotency-Key für Geld/Webhooks: Eine Wiederholung der Anfrage erzeugt keine zweite Belastung/Gutschrift.

mTLS an Wallet/Kasse/Anbieter: Transportverschlüsselung + gegenseitige Überprüfung der Parteien.

Beispiel für einen sicheren 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"
}

Eingangsvalidierung: Schemata und Kanonikation

JSON Schema/OpenAPI als Vertrag. Jede Zeile - durch die Validierung von Typen, Bereichen und Whitelists (ISO-Codes von Währungen/Ländern, enum Status).

Größenbeschränkungen: Begrenzung der Körpergröße und Arrays, Verbot von „tiefen“ Verschachtelungen.

JSON Kanonizierung vor Signaturen/Logs, Abschirmung von Sonderzeichen, streng 'Content-Type'.

Massenzuordnung sperren: Explizite Allow-Listen von Feldern.

Oberflächenschutz: WAF, Bots, Geschwindigkeit

WAF/Bot-Management: Signaturen und Verhaltenserkennung (Rate, Geo, Device-Fingerprint).

Rate limits/quotas: pro IP/Token/Client/Methode; separate Grenzen für Geld und Nicht-Geld.

DoS/Abuse-Kontrolle: Schaltkreisunterbrecher, Timeouts, Backpressure, „graue Listen“.

CORS: Punkt 'Access-Control-Allow-Origin', Wildcard-Verbot und 'Authorization' in Browser-Cross-Origin ohne Not.

OWASP API Top-10 → Konkrete Maßnahmen

BOLA/BFLA (Broken Object/Function Level Auth): ABAC nach Ressourcenbesitzer, Filter nach 'playerId', Verbot von „fremden“ IDs.

Injection/SSRF: parametrisierte Abfragen, Verbot externer URLs in Serveraufrufen, allowlist von Hosts.

Excessive Data Exposure: Formung von Antworten (Feldmaske), Paginierung, Normalisierung von Fehlern ohne Leckage von Teilen.

Sicherheitsabweichung: Einheitlichkeit der TLS-Versionen/Chiffren, Überschriften CSP/Permissions-Policy/Referrer-Policy.

Unsafe Verbrauch von APIs: Wrapper über Anbieter-APIs mit Timeouts, Retrays, Deduplizierung.

PII und Privatsphäre

PII Tokenisierung und Verschlüsselung (Spielerattribute, KYC Dokumente): KMS/HSM, Felder - AES-GCM.

Datenminimierung: in Ereignisse/Protokolle - nur Aliase ('playerId'), nie - Dokument-/Kartennummern.

Retention: Die TTL ist für Domains (Wallet/Game/Kasse) gemäß den Anforderungen der Gerichtsbarkeiten unterschiedlich.

Rollenbasierter Zugriff: Unterscheidung zwischen PII-Lesen auf Datenbank- und Service-Ebene (Row-Level-Sicherheit/Richtlinien).

Sichere Webhooks und Kasse

Zwei-Faktor-Prüfung: mTLS zum Webhook + HMAC-Signatur des Anbieters.

Anti-Replay: 'X-Idempotency-Key', 'X-Timestamp', Zeitfenster.

Allowlist IP/ASN Provider, statische ausgehende egress-IP bei uns.

„Giftige“ Payloads: Größenlimits, das Ignorieren ungenutzter Felder, ein strenges Schema.

Audit und Testendpunkt: Sandbox des Anbieters + Vertragstests.

Geheimnisse und Schlüssel

Speicherung: KMS/HSM/Secrets-Manager, nie in git/Umgebungsvariablen ohne Verschlüsselung.

Rotation: automatisch, 'kid' in Header/Metadaten, Rückruf von kompromittierten Schlüsseln.

Zugang: break-glass Verfahren, Protokollierung aller Zugriffe auf Geheimnisse.

Logs, Traces, Alerts

Korrelation: 'traceId/requestId/playerId/roundId' in jeder Ebene (ingress → API → Wallet → Provider → Webhook).

Anomalien: Anstieg von '401/403/429', Anstieg von 'VOID', Sprünge von 'bet'. reject 'nach Regionen, HMAC/mTLS-Fehlschläge.

Angriffssignale: viele' nonce' -Reviews, Versuche der alten 'timestamp', lange Körper, unbekannte' kid'.

Logspeicher: unveränderlich (WORM), separater Zugriffsbereich, PII-Maskierung.

Testplan und Qualitätskontrolle

Statisch/dynamisch AppSec: SAST/DAST auf jedem CI, Geheimsignaturen, Abhängigkeiten - SCA.

Pentests und Red-Tim: Replay-Skripte, Signatur auf falschem Kanal, Bypass Rate-Limits, BOLA, SSRF.

Vertragstests: auf OpenAPI/JSON-Schema, „negative cases“.

Chaos/Latenzbohrungen: Verhalten bei Timeouts von Anbietern/Kassen, Korrektheit der Idempotenz.

Bug-Bounty: Ein Programm mit separaten Perimeter- und Reportingregeln.

Nützliche Titel und Einstellungen

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

`Content-Security-Policy: default-src 'none'; frame-ancestors' none "(für API-Domains)

`Referrer-Policy: no-referrer`

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

`X-Content-Type-Options: nosniff`

„Cache-Control: no-store“ auf privaten Endpunkten

Fehlerantworten: einheitliches Format

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

Anti-Muster (das bricht die Sicherheit)

Langlebige JWT/Refresh-Token ohne Rotation und Bindung an das Gerät.

Die Signatur „as is“ ohne JSON-Kanonikalisierung → den Durchgang von Inspektionen.

Das Fehlen von „Idempotency-Key“ auf Geld/Webhooks → doppelte Abschreibungen.

Wildcard-CORS und "in 'Access-Control-Allow-Origin' für Endpunkte mit 'Authorization'.

Protokolle mit PII/Geheimnissen, Freigabe der Protokolle „für alle“.

Ein einziger gemeinsamer HMAC-Schlüssel für alle Integrationen.

Es gibt keine Grenzen für die Größe/Tiefe von JSON, keine Timeouts und Circuit-Breakers.

Fehler, die interne Details offenbaren (Stack Traces, SQL, Bibliotheksversionen).

Casino API Sicherheits-Checkliste

Perimeter und Transport

mTLS auf dienste- und anbieterübergreifenden Kanälen; TLS 1. 3 überall.
API-Gateway mit WAF/Bot-Management, Ratenbegrenzung, Threat-Feeds.
CORS - nur adressierbar, keine Wildcard.

Authentifizierung/Autorisierung

OAuth2/OpenID für Kunden, JWT mit TTL ≤ 10 min, Schlüsselrotation ('kid').
RBAC/ABAC nach Bereichen; admin - SSO + MFA + IP-allowlist.

Integrität und wiederholte Anfragen

HMAC-Signatur, 'X-Request-Timestamp', 'X-Request-Nonce' und Zeitfenster.
„X-Idempotency-Key“ auf Geld, Webhooks, Kasse; Schlüssel im Cache speichern.

Validation

OpenAPI/JSON-Schema, JSON-Kanonizierung, Größen-/Tiefengrenzen.
Maskierung und Whitelists für Felder; Verbot der Massenbelegung.

PII und Daten

PII Tokenisierung/Verschlüsselung (KMS/HSM), Minimierung, individuelle Retentionsrichtlinien.
Geteilte Speicher für PII/Telemetrie/Geld.

Integration

Webhooks: mTLS + HMAC, allowlist IP, Anti-Replay, Vertragstests.
Kasse/Krypto: zwei Anbieter und verschiedene Schlüssel/Netzwerke, idempotency in/out.

Beobachtungsstand

Tracing mit 'traceId/playerId/roundId', Warnungen vor Angriffssignalen.
Protokolle unveränderlich (WORM), ohne PII/Geheimnisse.

Prozesse

SAST/DAST/SCA in CI, Pentests/Red-Tim regelmäßig, Bug-Bounty.
Runbooks Vorfälle: revoke Schlüssel, Rollback, Kommunikation.

Bei der API-Sicherheit in iGaming geht es nicht darum, „WAF zu setzen“. Es ist ein System: mTLS + Signaturen + Idempotenz, strenge Validierung und Kanonikation, Perimeter- und Geschwindigkeitsschutz, PII-Isolation, sichere Kassen-Webhooks, Beobachtbarkeit und regelmäßige Kontrollen. Indem Sie dies zu einem Teil der Engineering-Kultur machen, schützen Sie Geld, Spieler und Lizenz, während Sie die Geschwindigkeit des Produkts und die Stabilität der Veröffentlichungen beibehalten.