API-Sicherheit und Anforderungsfilterung

1) Warum es notwendig ist

API - Die externe und interne Grenze der Plattform. Jeder Fehler bei der Authentifizierung, Autorisierung, Validierung oder Normalisierung von Anfragen wird in die Ausnutzung von Schwachstellen (BOLA/IDOR, Injektion, SSRF, Massenüberschreitungen, Ressourcenverschwendung) umgewandelt. Ziel: Schaffung eines mehrstufigen Schutzes (Defense-in-Depth) vom Perimeter bis zu den Geschäftsregeln, mit messbaren SLOs und Risikokontrolle.

2) API-Inventar und Klassifizierung

API-Verzeichnis: Register aller Dienste/Endpunkte, Besitzer, Versionen, Kundentypen (Web, Mobile, Partner), Modus (öffentlich/Partner/intern), PII/Daten.
Kritikalität: Hoch (Finanztransaktionen/Autorisierung), Mittel (Leseprofil), Niedrig (öffentliche Verzeichnisse).
Angriffsfläche: REST, GraphQL, gRPC, WebSocket, Webhooks.
Status: prod/staging/experimental, Deprecate Policy, Lebensdauer der Token/Schlüssel.
Schatten/verlassene APIs: Erkennung über Log-Ingrest, eBPF/Service Mesh Telemetrie, Vergleich mit Verzeichnis.

3) Bedrohungsmodell (kurz)

Identifikation: Token-Hijacking, Session-Fix, MitM, Replay.
Autorisierung: BOLA/IDOR, horizontale/vertikale Eskalation.
Input: Injections (SQL/NoSQL/LDAP), Template/Serialisierung, Path Traversal, Header.
Traffic: DDoS/L7-Floods, langsame Anfragen, Phantom-Retrays.
Integrationen: unsichere Webhooks, SSRF über URL-Parameter, Datei-Downloads/Scans.
Logik: Bonusmissbrauch, Rennen, Inkonsistenz der Idempotenz.

4) Grundlegender Sicherheitsstandard (Minimum)

1. TLS 1. 2 + überall; HSTS; Schwache Chiffren sind deaktiviert.
2. Authentifizierung: OAuth2/OIDC für Kunden, mTLS/oder HMAC - Service-to-Service.
3. Autorisierung: Zentralisierte PDP (RBAC/ABAC), Validierung auf Objektebene (BOLA).
4. Validierung: Striktes Schema (OpenAPI/JSON Schema/Protobuf), Ausfall bei überflüssigen Feldern.
5. Limits: rate/quotas + burst, per client/per-IP/per-token.
6. Idempotenz bei Schreiboperationen, Schutz vor Wiederholungen/Rennen.
7. WAF/Gateway-Filterung: Normalisierung von Pfaden/Headern, Deny-Sheets, Payload-Anti-Pattern-Block.
8. Geheimnisse: KMS/Vault, Schlüssel-/Zertifikatsrotation, Leckkontrolle.
9. Beobachtbarkeit: Tracing, Sicherheits-Audit-Protokolle (wer/was/wann/Ergebnis), Alerts.
10. Verfahren: Incident Playbook, Testfälle und regelmäßige Pentests/DAST.

5) Authentifizierung und Token-Management

OAuth2/OIDC: kurzlebige Access-Token, Refresh streng nach OIDC; audience/issuer/exp werden auf dem Gameplay überprüft.
JWT: RS256/ES256; ein Mindestsatz von Klimes; "nbf/exp/aud' ist obligatorisch; Verbot der Lagerung von PII. Schlüsselrotation über JWKS.
DPoP/PoP: Binden des Tokens an den Kundenschlüssel, um das Risiko von Replay/Hijacks zu reduzieren.
mTLS für interne Systeme und vertrauenswürdige Partner (CN/SAN-Zertifizierung, CRL/OCSP).

HMAC (Signaturen): deterministische Kanonikation (Methode + Pfad + Timestamp + Nonce + Body-Hash); Zeitfenster (± 300s)

Browser-Sitzungen: SameSite = strict/lax, HttpOnly, Secure; Schutz vor CSRF (double submit/state token).
Kundenspeicher: auf dem Mobil - sichere Speicher (Keychain/Keystore), Schutz vor Debag, Pinning von Zertifikaten.

6) Autorisierung (BOLA-first)

Object-level: Jede Operation prüft das Recht auf eine bestimmte Ressource (Resource Owner/Scope/Attribute).
RBAC/ABAC: Rollen + Attribute (Land, Segment, Risikolimits, KYC-Ebene).
Richtlinien: deny-by-default; explizite allow; Versionierung von Richtlinien; Tests für negative Fälle.
Lösungs-Cache: Adaptive TTL + Behinderung bei Rollen-/Segmentwechsel.

7) Filterung und Normalisierung von Anfragen (auf der Gateway/WAF)

Normalisierung: Re-Slash-Komprimierung, Verbot '../', einmalige Decodierung, Leerzeichen/Nullbyte-Trimmen.
Header: allow-list ('Host', 'Content-Type', 'Accept', 'Authorization', 'Date', 'Idempotency-Key', benötigte Trace-Header).
Methoden: 'GET/HEAD' ohne Körper; 'POST/PUT/PATCH' - mit dem Typ 'application/json' oder streng erlaubt.
Größen: max-body, max-headers, max-path; early-reject 413/431.
Dateien: MIME-Validator, Antivirus/Sandbox, Verbot aktiver Inhalte, Bildbearbeitung/-sanierung.
URL-Weiterleitungen/Fetchi: SSRF-Block (deny private ranges/metadata IP, Schema nur 'https', allow-list domains).
SQL/NoSQL-Muster: Injektionssignaturen über WAF-Regelsätze + serverseitige Parametrisierung von Abfragen.

Beispiel für eine Überschriftenrichtlinie (Pseudoformat)

deny_headers: ["X-Forwarded-Proto","X-Original-URL","Proxy-Connection","Destination"]
require_headers: ["Authorization" (для protected), "Content-Type" (для write)]
strip_duplicates: true max_header_count: 32 max_header_size: 16KB

8) Limits, Quoten und Anti-Bot-Schutz

Rate limiting: token-bucket/ leaky-bucket; Ebenen - pro IP, pro API-Schlüssel, pro Benutzer, pro org.
Quotas: täglich/monatlich, getrennt für write/expensive Methoden.
Anpassungsfähigkeit: Dynamische Straffung bei Anomalien (sudden burst/credential stuffing).
Slow-loris/slow-POST: Lese-Timeouts/Keep-alive, Einschränkung paralleler Verbindungen.
Antibot: Device-Fingerprint, Verhaltenszeichen, Proof-of-Work/Captcha auf erhöhtes Risiko, Liste der Tor-/Proxy-Netzwerke.
IP-Steuerung: Geo-/ASN-Filter, Deny-Sheets von „schmutzigen“ Subnetzen, Allow-Sheets für Partner/Admin-Panels.

9) Validierung von Inputs und Schaltungen

Fail-closed: Alles, was das Schema nicht durchläuft, ist 400. Überflüssige Felder sind abzulehnen.
Typen/Bereiche: Zahlen, Daten (UTC/ISO-8601), Enum-Werte, Zeilenlängen, Regexes.
JSON-Qualität: max-nesting, Verbot großer Arrays/Schlüssel, canonical order (optional).
Geschäftliche Validierung: Idempotency nach „Idempotency-Key“; Anti-Betrugsregeln (Transaktionshäufigkeitslimits, amount caps).
GraphQL: depth/complexity-limits, allow-listed queries, per-field authorization.
gRPC: strenge Protobuf-Schemata, Pflichtfelder, Nachrichtengrößenlimits.

10) Webhooks und externe Herausforderungen

Bildunterschriften: HMAC mit Zeitstempel/nonce; Überprüfung vor der Verarbeitung; Fenster +/- 5 Min.
Lieferung: Retrays mit exponentieller Pause und Jitter; Max-Versuche; Deduplizierung nach Ereignis-ID.
IP allow-list des Lieferanten; separate Subdomain/Pfad; Minimaler Hosting-Stack.
Antworten: 2xx nur nach erfolgreicher interner Aufzeichnung; ansonsten 4xx/5xx mit klarem Code.
Ausgehende SSRF-Kontrolle: bei callback URL - allow-list, Verbot von privaten Adressen.

11) Verschlüsselung und Verwaltung von Geheimnissen

Im Kanal: TLS 1. 2+/1. 3, Pinning, strenge Chiffrierpolitik.
Allein: DB/Object-Storage-Verschlüsselung, separate Schlüssel für PII/Daten.
KMS/Vault: zentrale Geheimhaltung, kurze TTLs, automatische Rotation.
Schlüssel und Zertifikate: getrennt für Umgebungen; Prüfung der Ausgaben; Verbot der Ausgabe in Logs.
Token-introspection: Offline-Abruflisten (Revocation), kurz' exp'.

12) Beobachtbarkeit, Auditierung und Reaktion

Sicherheitsprotokolle: Authentifizierungsversuche/-erfolge, Autorisierungsfehler, Rate-Limit-Ereignisse, Rollen-/Limitänderungen.
Tracing: correlation-ID durch; externe Anrufe verfolgen.
Metriken: RPS, P95/P99 Latenz, Fehlerrate durch Codes, Anteil der 401/403/429, Hit-Rate-Limits, Anomalien.
Alertas: 401/403/429, 5xx Wachstum, häufige idempotency-Konflikte, scharfe Abweichungen graphQL-complexity.
Playbooks: Schlüssel/Token sperren, Regeln schnell zurücksetzen, Deny-Liste aufwärmen, Servicebesitzer benachrichtigen.
Forenzika: Beibehaltung der umstrittenen Payload (mit sicherer PII-Bearbeitung), Replikation auf einem isolierten Stand.

13) Fehler und Antworten an den Kunden

Einheitliches Fehlerformat (Code, Nachricht, Trace-Id, Kategorie).
Keine Lecks: SQL, Tabellennamen, interne Aidis nicht offenlegen; 403 statt „warum eigentlich nicht“.
Codes: 400 (Validierung), 401 (keine Authentifizierung), 403 (keine Rechte), 404 (Existenz verschleiern), 405/406, 413/429, 500/503.
Retry-Hints: для 429 — `Retry-After`; für Idempotenz - Wiederholungstipp mit dem gleichen Schlüssel.

14) Architektonische Muster

Zero-Trust: mTLS, explizite Autorisierung zwischen allen Diensten, minimale Privilegien.
API-Gateway + WAF + Service-Mesh: Aufgabenteilung - Perimeter, L7-Richtlinien, interne Authentifizierung.
Canary/Blue-Green: Die neuen Filterregeln Schritt für Schritt mit Aufsicht ausrollen.
Fail-closed: für kritische Schreiben - es ist besser, sicher zu verweigern, als eine falsche Operation zuzulassen.
Backpressure: Warteschlangen/Puffer, Circuit Breaker, Timeouts/Budgets.

15) Beispiele praktischer Regeln (Pseudo-Config)

15. 1 Einschränkung von Wegen und Methoden

/api/v1/payments:
allow_methods: [POST, GET]
auth: oauth2_required body:
content_type: application/json max_size: 256KB

15. 2 Idempotenz

require_header: Idempotency-Key (UUIDv4)
store: redis:ttl=24h on_duplicate: return_previous_result

15. 3 Signatur der Anforderung (HMAC)

signature:
scheme: "HMAC-SHA256"
required_headers: ["X-Signature","X-Timestamp","X-Nonce"]
allowed_drift: 300s string_to_sign: METHOD + "\n" + PATH + "\n" + SHA256(body) + "\n" + X-Timestamp + "\n" + X-Nonce

15. 4 SSRF-Schutz

outbound_http:
allowlist_domains: ["kyc. partner. com","psp. example. net"]
block_private_ip: true require_https: true

15. 5 GraphQL Limit

graphql:
max_depth: 8 max_complexity: 500 allowlisted_operations_only: true

16) Spezifität von iGaming/Finanzen

Segmentlimits: abhängig vom KUS/Land/Risikoprofil.
Zeitfenster: Regeln für die Häufigkeit von Einzahlungen/Auszahlungen, „Abkühlung“ zwischen Transaktionen.
Anti-Missbrauchs-Boni: konsistente Sperren pro Konto/Gerät/IP/Zahlungsinstrument.
Regulatory Requirements Audit: Speicherung von Aktionsprotokollen und Entscheidungen (KYC/AML), Retention Perioden, unveränderliche Protokolle.

17) Prod-Readiness Checkliste

• Vollständiger API-Katalog und Datenflusskarte (PII/Finanzen markiert).
• OpenAPI/Protobuf-Schemata, Validierungstests und Verträge im CI.
• mTLS/HMAC/OAuth2 eingerichtet sind; kurze TTL-Token; Rotation der Schlüssel.
• BOLA-Tests und Negativgenehmigungsfälle; zentralisiertes PDP.
• Grenzwerte/Quoten/Anti-Bot, Schutz gegen Slow-Loris; IP-Filter.
• WAF/Gateway-Regeln Normalisierung, Anti-injizierbare Signaturen.
• Idempotenz der Schreiboperationen; Schutz vor Replay.
• Webhook-Signaturen und allow-list; isolierte Endpunkte.
• Geheimnisse in KMS/Vault; verschlüsselte Toragi; Hinweise auf Anomalien.
• Dashboards, Alerts, Audit-Logs; geübte Playbooks von Vorfällen.
• Regulärer Pentest/DAST/SAST, Spuren von Schwachstellen und Deploy Patches.

18) Antipatterns (was nicht möglich ist)

Vertrauen Sie' X-Forwarded- 'ohne harte TLS-Terminierung an Ihrem Perimeter.
Akzeptieren Sie beliebige' Content-Type' und 'weiche' JSON-Schemata.
Langlebige JWTs ohne Rückruf/Rotation.
Mischen Sie Rollen und Geschäftsregeln in Code ohne zentrale Richtlinien.
Protokolle mit Geheimnissen/PII; detaillierte 500-Nachrichten nach außen.
„Temporäre“ offene Endpunkte ohne Limits und Autorisierung.

19) Versionierung und Deprecate

Versionen im Pfad/Header; Unterstützungspolitik (z. B. N-2).
Ankündigungen: Deprecate Timing, Überwachung der Nutzung älterer Versionen, kontrollierte Abschaltung.
Kompatibilität: Verträge und Testmatrizen von Kunden/Partnern.

20) Sicherheitsprüfung

Vertragsschematests/Richtlinien, fuzzing Eingänge, negative auth.
Leistungsprofile mit Limits/Quoten, Schutzprüfung (Chaos-Verkehr).
Red-team/bug-bounty: BOLA-Skripte, SSRF, Signaturen/Replays, GraphQL-complexity.

TL; DR

1. API-Verzeichnis + strenge Schemata.
2. OAuth2/OIDC für Kunden, mTLS/HMAC innen.
3. BOLA-Perimeter für jede Ressource (ABAC/RBAC).
4. Filterung: Normalisierung von Pfaden/Headern, Limits, WAF-Regeln.
5. Idempotenz, Signaturen, Replay/SSRF-Schutz.
6. KMS/Vault und die Rotation der Geheimnisse.
7. Observability, Alerts, Playbooks.