Wenn Sie Services in Produktion betreiben, sind Ihre APIs Ihre Angriffsfläche. Die spektakulärsten API-Breaches der letzten Jahre beruhten nicht auf exotischen Exploits — es waren gewöhnliche, wohlgeformte Requests, die Objekte anforderten, die der Aufrufer nie hätte sehen dürfen. Die OWASP API Security Top 10 existieren, weil sich diese Fehlermuster mit bemerkenswerter Beständigkeit wiederholen. Eine API im Jahr 2026 abzusichern bedeutet, eine kurze Liste von Dingen rigoros umzusetzen. Hier ist diese Liste.

Transport: TLS 1.2 oder 1.3, sonst nichts

"SSL" ist seit über einem Jahrzehnt veraltet; wenn ein Dokument noch von SSL spricht, lesen Sie es als TLS und prüfen Sie, welche Versionen tatsächlich aktiviert sind. Liefern Sie standardmäßig TLS 1.3 aus, behalten Sie TLS 1.2 als Untergrenze für Legacy-Clients und deaktivieren Sie alles Ältere. Ergänzen Sie HSTS, damit Clients nie auf Klartext zurückfallen:

# nginx — nur TLS 1.2/1.3, kein Downgrade auf HTTP
ssl_protocols TLSv1.2 TLSv1.3;
ssl_prefer_server_ciphers off;
add_header Strict-Transport-Security "max-age=63072000" always;

Authentifizierung: OAuth 2.0 und OIDC, API-Keys an ihrem Platz

Für nutzerorientierte APIs ist der Standard OAuth 2.0 mit kurzlebigen Access Tokens, ergänzt um OpenID Connect, wenn Sie eine verifizierte Nutzeridentität benötigen. Für Machine-to-Machine-Aufrufe verwenden Sie den Client Credentials Grant. API-Keys haben weiterhin eine Rolle, aber verstehen Sie, was sie sind: Identifikatoren, keine starke Authentifizierung. Für Nutzungszuordnung und Quotendurchsetzung an risikoarmen Endpoints sind sie in Ordnung; als Zugriffskontrolle für sensible Operationen taugen sie nicht. Rotieren Sie sie und halten Sie sie aus URLs und clientseitigem Code heraus. Eines gehört nicht auf diese Liste: Biometrie — ein Fingerabdruck authentifiziert einen Menschen gegenüber einem Gerät; was bei Ihrer API ankommt, ist weiterhin ein Token, und das Token ist es, was Sie validieren müssen.

JWTs bündeln mehrere klassische Fehler. Pinnen Sie die akzeptierten Signaturalgorithmen und weisen Sie alg: none zurück; validieren Sie exp, iss und aud bei jedem Request; beziehen Sie die Verifikationsschlüssel vom JWKS-Endpoint des Issuers, damit die Schlüsselrotation ohne Redeploys funktioniert; und halten Sie Access-Token-Laufzeiten in Minuten, nicht in Tagen.

Autorisierung: BOLA ist die API-Schwachstelle Nummer eins

Broken Object Level Authorization führt die OWASP-API-Liste seit 2019 an und bleibt der häufigste API-Fehler in der Praxis: ein Request auf /invoices/8371 mit einem völlig gültigen Token, das einem anderen Kunden gehört. Die Abhilfe ist unglamourös — prüfen Sie die Objekt-Eigentümerschaft bei jedem Request, innerhalb des Services, dort, wo die Datenbeziehungen leben. Zwei Geschwister verdienen dieselbe Behandlung: Function-Level Authorization (Admin-Endpoints, die mit Nicht-Admin-Tokens erreichbar sind) und Property-Level Authorization, bei der Mass Assignment einem Client erlaubt, Felder wie role oder price zu setzen, die nie beschreibbar sein sollten. Setzen Sie die Properties, die Clients senden dürfen, auf eine Allow-List.

Eingaben gegen ein Schema validieren

Definieren Sie die API in OpenAPI und erzwingen Sie dieses Schema am Gateway oder in der Middleware: Typen, Wertebereiche, Längen, Formate und die Zurückweisung unbekannter Felder. Injection ist nicht verschwunden, nur weil APIs die Webformulare abgelöst haben — alles, was eine Datenbank, eine Shell oder ein Template erreicht, muss weiterhin parametrisiert werden. Output Encoding, das oft neben diesen Kontrollen aufgeführt wird, ist in Wahrheit eine XSS-Abwehr für Browser, die die Daten Ihrer API rendern; es schützt den Client, nicht die API — zählen Sie es also nicht als API-seitige Kontrolle.

Rate Limiting und Missbrauchskontrollen

Setzen Sie Limits pro Client, gebunden an das Token oder die Client-ID, liefern Sie 429 mit Retry-After zurück und stimmen Sie die Limits pro Endpoint ab — Login- und Passwort-Reset-Routen deutlich strenger als Lesepfade. Diese eine Kontrolle entschärft Credential Stuffing, das Durchprobieren von Objekt-IDs, Scraping und die Ressourcenerschöpfungsangriffe, die OWASP unter Unrestricted Resource Consumption führt. Kombinieren Sie sie mit Obergrenzen für Request-Größe und Pagination, damit eine einzelne teure Abfrage dem Angreifer nicht die Arbeit abnimmt.

Gateways am Edge, mTLS im Inneren

Ein API-Gateway — AWS API Gateway, Kong, Apigee oder ein Envoy-basiertes Setup — gibt Ihnen einen zentralen Ort, um TLS-Terminierung, Token-Validierung, Schema-Prüfungen, Rate Limits und WAF-Integration richtig zu machen, statt sie pro Service neu zu implementieren. Was das Gateway nicht leisten kann, ist Object-Level Authorization: Diese Logik bleibt in den Services. Für Service-zu-Service-Traffic verwenden Sie Mutual TLS, damit sich beide Seiten gegenseitig authentifizieren; ein Service Mesh wie Istio oder Linkerd oder ein SPIFFE/SPIRE-Deployment stellt Workload-Zertifikate automatisch aus und rotiert sie — nur so überlebt mTLS den Kontakt mit dem realen Betrieb.

Und schließlich: Instrumentieren Sie das alles. Gateway- und Authentifizierungslogs gehören zu den wertvollsten Detection-Quellen, die Sie besitzen: Streamen Sie sie in Ihre SIEM- und Detection-Pipeline und alarmieren Sie auf Token-Anomalien und Spitzen bei 401ern und 403ern. Wenn Sie einen strukturierten Review eines bestehenden API-Bestands gegen diese Checkliste wünschen, ist das genau die Arbeit unserer SecOps-Practice. Für plattformspezifisches Hardening ist der API-Gateway-Schutzleitfaden von AWS eine solide Referenz.

Möchten Sie das gegen Ihre Accounts prüfen lassen? Unser AWS Security Assessment umfasst 98 Prüfpunkte, gemappt auf ISO 27001, SOC 2, NIS2 und DORA — Festpreis, Nachweise inklusive.

Tags: #APISicherheit #OAuth2 #mTLS #OWASP