Wissen · Sicherheitsleitfaden

API- und Gateway-Sicherheit: der praxisnahe Leitfaden

Eine API sicherst du ab, indem du prüfst, wer anfragt, worauf genau er zugreifen darf und wie viel er tun darf, und diese Prüfungen sowohl am Gateway als auch im Backend durchsetzt. Ein Gateway ist ein starker Kontrollpunkt, ersetzt aber keine Autorisierung in der Anwendung und ist selbst Software, die Updates braucht. Dieser Leitfaden behandelt die wichtigsten Risiken, eine Härtungs-Checkliste, Patching, Inventar, Tests und Reaktion.

Aktualisiert: 6. November 2026

Warum APIs und Gateways im Visier stehen

APIs machen Geschäftsfunktionen und Daten strukturiert und vorhersehbar zugänglich. Dadurch lassen sie sich für Angreifer leicht erkunden und automatisieren. Ein API-Gateway steht vor vielen Diensten. Eine Schwachstelle darin, etwa eine umgehbare Authentifizierung oder ein fehlendes Rate Limit, kann deshalb alles dahinter betreffen.

Wenn Medien über eine Lücke in einem verbreiteten Gateway berichten, ist Routine besser als Aufregung: Du weißt, welche Gateways und Plugins im Einsatz sind, kennst ihre Versionen und kannst schnell aktualisieren. Verbreitete Gateways sind zum Beispiel Kong, Tyk, Apigee, Amazon API Gateway und Azure API Management. Sie sind nur Beispiele, und die folgenden Grundsätze gelten für alle.

Die OWASP API Security Top 10

Die OWASP-Liste ist der übliche Ausgangspunkt für API-Risiken. Stand November 2026 ist weiterhin die Ausgabe von 2023 aktuell; auf den Projektseiten ist keine neuere zu finden. Nutze sie als Checkliste für Design-Reviews und Tests. Die zehn Kategorien sind:

• API1: Broken Object Level Authorization
• API2: Broken Authentication
• API3: Broken Object Property Level Authorization
• API4: Unrestricted Resource Consumption
• API5: Broken Function Level Authorization
• API6: Unrestricted Access to Sensitive Business Flows
• API7: Server Side Request Forgery
• API8: Security Misconfiguration
• API9: Improper Inventory Management
• API10: Unsafe Consumption of APIs

Das Gateway härten

Beginne bei der Identität. Authentifiziere jede Anfrage mit etablierten Standards statt mit selbstgebauten Verfahren. OWASP betont, dass API-Keys allein keinen Nutzer identifizieren und sensible Ressourcen nicht alleine schützen sollten. Wenn du JWTs einsetzt, lehne unsignierte Token ab, wähle den Prüfalgorithmus aus deiner eigenen Konfiguration statt aus dem Token-Header und prüfe Aussteller, Zielgruppe und Ablaufzeit.

Autorisierung braucht zwei Ebenen. Prüfungen auf Objektebene stellen sicher, dass der Aufrufer auf genau den angefragten Datensatz zugreifen darf; die klassische Attacke ist, eine ID im Pfad auszutauschen, und nicht erratbare IDs helfen nur als zusätzliche Schicht. Prüfungen auf Funktionsebene verweigern standardmäßig den Zugriff und vergeben jede Funktion rollenbasiert, ohne aus dem URL-Pfad abzuleiten, ob ein Endpunkt administrativ ist. Das Gateway kann grobe Regeln durchsetzen, die endgültige Entscheidung über ein Objekt gehört aber meist in den Dienst, der die Daten besitzt.

Kontrolliere den Verbrauch. Setze Rate Limits und Kontingente pro Client, wende strengere Grenzen auf sensible Vorgänge wie Passwort-Wiederherstellung oder Einmalcodes an, begrenze Anfrage- und Payload-Größen und lege für kostenpflichtige Drittanbieter-APIs Ausgabelimits oder Abrechnungsalarme fest. Azure API Management dokumentiert zum Beispiel Kontingente und Rate Limits als Gateway-Richtlinien, andere Produkte bieten Vergleichbares.

Validiere Ein- und Ausgaben. Prüfe Typ, Länge, Format und Wertebereich, erlaube nur die HTTP-Methoden und Inhaltstypen, die jede API braucht, liefere saubere Fehlermeldungen ohne Stacktraces und protokolliere Validierungsfehler, denn ein Anstieg deutet oft auf Abtasten hin. Verschlüssele den gesamten Verkehr per TLS, auch zwischen Gateway und Backends, und erwäge mutual TLS für hoch privilegierte oder Maschine-zu-Maschine-Verbindungen. Lege Geheimnisse wie Schlüssel und Zertifikate in einem Secrets-Manager ab, rotiere sie und halte sie aus Konfigurationsdateien in der Versionsverwaltung heraus.

• Standardmäßig verweigern, dann pro Rolle und Objekt erlauben
• Rate Limits, Kontingente und Größenlimits auf jeder Route
• TLS überall, mutual TLS für sensible Dienstverbindungen
• Geheimnisse im Tresor, kurzlebige Token, Rotation
• Admin- und Verwaltungsschnittstellen in einem getrennten, beschränkten Netz
• Strukturierte Logs mit Request-ID, ohne Geheimnisse und personenbezogene Daten

Gateways und Plugins aktuell halten

Ein Gateway ist aus dem Internet erreichbare Software mit eigenen Abhängigkeiten und Plugins von Drittanbietern. Führe eine Liste aller Gateways, Versionen und Plugins, auch der selbst entwickelten, und benenne für jedes einen Verantwortlichen. Abonniere den Sicherheitshinweis-Kanal oder die Release Notes des Herstellers und lies die Support-Richtlinie für Versionen, damit du weißt, wie lange deine Version Korrekturen erhält.

Support-Zeiträume sind wichtig. Kong nennt etwa ein Jahr Support für reguläre Minor-Versionen und bis zu drei Jahre für Versionen mit Langzeit-Support; danach folgt eine Auslaufphase ohne Patches. Andere Hersteller haben eigene Regeln, lies sie also, bevor du eine Version wählst.

Das NIST hat Richtlinien zum API-Schutz in Cloud-nativen Systemen als SP 800-228 im Juni 2025 veröffentlicht und im März 2026 aktualisiert. Sie beschreiben Basis- und weiterführende Maßnahmen für die Phasen vor und während der Laufzeit im API-Lebenszyklus und taugen als Referenz für eine risikobasierte Roadmap. Wenn ein Hinweis dich betrifft, teste das Update in einer Staging-Umgebung, spiele es zügig aus und prüfe die Logs aus der Zeit vor dem Patch auf frühere Angriffe.

API-Inventar und Schatten-APIs

Was du nicht kennst, kannst du nicht schützen. OWASP führt unzureichendes Inventar als Risiko, weil vergessene Hosts, alte Versionen und undokumentierte Endpunkte oft keine aktuellen Schutzmaßnahmen haben und alte Versionen sogar dieselbe Datenbank wie die Produktion nutzen können. Angreifer finden sie mit einfachen Mitteln wie DNS-Enumeration und Suchmaschinen.

Erfasse jeden API-Host mit Umgebung, Zielgruppe und Version. Dokumentiere Endpunkte, Authentifizierung und Limits aus einer maschinenlesbaren Spezifikation in deiner CI/CD-Pipeline. Lege für jede Version einen Außerbetriebnahme-Plan fest, schütze alle erreichbaren Versionen und nicht nur die neueste und halte Produktivdaten aus Testsystemen heraus. Gleiche dein Inventar mit dem ab, was Traffic-Logs und DNS tatsächlich zeigen, um Schatten-APIs zu finden.

APIs testen

Kombiniere mehrere Methoden. Automatische dynamische Scanner importieren eine OpenAPI-, SOAP- oder GraphQL-Definition und prüfen jeden Endpunkt; der Open-Source-Scan von ZAP ist ein Beispiel, und er führt standardmäßig aktive Angriffe aus, richte ihn also auf eine Testumgebung. Fuzzing sendet fehlerhafte und unerwartete Eingaben, um Schwächen bei Parsing und Fehlerbehandlung zu finden.

Logikfehler in der Autorisierung finden Automaten selten, etwa wenn ein Kunde die Bestellung eines anderen liest. Dafür ist der manuelle Penetrationstest da: Ein Tester arbeitet mit mehreren Konten und Rollen und versucht, die Grenzen zu überschreiten. Schreibe außerdem automatische Autorisierungstests in deine eigene Pipeline, damit eine Änderung, die sie bricht, nicht ausgeliefert wird. Teste nach größeren Gateway-Upgrades und Konfigurationsänderungen erneut.

Monitoring und Incident Response

Protokolliere Authentifizierungsfehler, Token-Prüffehler, abgelehnte Autorisierungen, Rate-Limit-Treffer und administrative Änderungen und leite sie an ein zentrales Monitoring. Sinnvolle Alarme sind ein plötzlicher Anstieg von 401-, 403- oder 429-Antworten, Enumerationsmuster über fortlaufende IDs und Verkehr zu Endpunkten, die ungenutzt sein sollten.

Bereite ein Playbook vor, bevor du es brauchst. Es sollte regeln, wie Schlüssel und Token widerrufen werden, wie du einen Client oder eine Route am Gateway sperrst, wer eine Konfiguration zurückrollen darf, wie Logs gesichert werden und wer über die Information von Kunden und Behörden entscheidet. Übe es einmal und nimm den Support-Kontakt des Herstellers auf.