Was ist API-Sicherheit?
API-Sicherheit bezeichnet Strategien und technische Maßnahmen, mit denen die spezifischen Schwachstellen und Sicherheitsrisiken von Programmierschnittstellen verstanden und verringert werden.
Technische Einordnung: Sie ist keine einzelne Funktion und kein einzelnes Produkt. Sie verbindet die Ermittlung von Risiken und Schwachstellen mit geeigneten Schutzmaßnahmen während Entwicklung, Bereitstellung, Integration und Betrieb einer API.
Für wen ist API-Sicherheit relevant?
API-Sicherheit betrifft Organisationen sowie Entwicklungs-, Plattform-, Betriebs- und Sicherheitsteams, die interne oder externe APIs entwerfen, entwickeln, bereitstellen, integrieren oder betreiben. NIST SP 800-228 upd1 behandelt unmittelbar Cloud-native Unternehmenssysteme, beschreibt die zugrunde liegenden technischen Prinzipien jedoch als auf APIs und Kommunikationsstile übertragbar. Daraus folgt kein allgemeiner Rechtsanwendungsbereich.
Wann wird ein API-Sicherheitsprogramm nötig?
Der technische Auslöser ist der Einsatz oder die Einführung von APIs, bei denen während der Entwicklung oder zur Laufzeit Risiken beziehungsweise Schwachstellen bestehen können. Einen einzigen universellen Auslöser gibt es nicht. Kontrollen sollten inkrementell und anhand der jeweiligen Architektur, Daten, Geschäftsprozesse, Einsatzumgebung und Risiken ausgewählt werden.
Welche Kontrollen gehören zur API-Sicherheit?
Zu den wesentlichen Prüffeldern zählen Authentisierung, Autorisierung auf Objekt-, Eigenschafts- und Funktionsebene, Eingabevalidierung, Begrenzung des Ressourcenverbrauchs, sichere Konfiguration, ein gepflegtes API-Inventar und der sichere Umgang mit integrierten Fremd-APIs. Authentisierung und Autorisierung sind getrennt zu prüfen. Empfängt ein Endpunkt eine vom Client übermittelte Objektkennung und führt damit eine Aktion auf einem Objekt aus, sollte eine Objektberechtigungsprüfung erfolgen, damit angemeldete Nutzer nur erlaubte Aktionen ausführen können.
Nicht jede API weist jedes Risiko auf. Auswahl und Tiefe der Kontrollen müssen deshalb zum konkreten Risiko und zur Architektur passen und Schutzmaßnahmen vor der Laufzeit sowie während der Laufzeit verbinden.
Reichen ein API-Gateway oder eine Netzgrenze aus?
Nein. Ein Gateway oder eine Netzgrenze gewährleistet keine vollständige API-Sicherheit. Nach dem von NIST herangezogenen Zero-Trust-Ansatz dürfen interne Aufrufer nicht allein wegen ihrer Position als vertrauenswürdig gelten. Auch interne APIs und Aufrufe benötigen angemessene Prüfungen. Ebenso dürfen interne oder von Dritten stammende Daten nicht allein aufgrund ihrer Herkunft als vertrauenswürdig behandelt werden.
Welche Grenzen hat die OWASP API Security Top 10?
Die OWASP API Security Top 10 ist eine autoritative technische Orientierung zu häufigen Risikofeldern. Sie ist weder eine vollständige Einzelfall-Risikoanalyse noch eine universelle Kontrollspezifikation und ersetzt keine weiteren einschlägigen OWASP-Projekte. Die konkrete Risikobewertung muss die jeweilige API und ihren Einsatzkontext berücksichtigen.
Gibt es allgemeine Fristen oder Schwellenwerte?
Aus den herangezogenen technischen Leitlinien lässt sich für API-Sicherheit keine einheitliche Frist, kein allgemeiner Startzeitpunkt und kein universeller numerischer Schwellenwert ableiten. Grenzen wie Rate-Limits, Größenlimits oder Zeitfenster sind risikobasiert für die jeweilige API und den jeweiligen Geschäftsprozess festzulegen. Abweichende konkrete Vorgaben können sich aus anwendbaren Regelwerken, Verträgen, Diensten oder internen Vorgaben ergeben; mögliche Spezialregime sind mit den verwendeten technischen Quellen nicht abschließend bewertet.
Häufige Fehlannahmen
- „Ein API-Gateway löst das Sicherheitsproblem.“ Ein Gateway ist nur eine mögliche Kontrolle und ersetzt keine risikobasierte Absicherung der API und ihrer Funktionen.
- „Interne APIs und Daten sind automatisch vertrauenswürdig.“ Die Herkunft innerhalb einer Netzgrenze ersetzt weder Identitäts- noch Berechtigungs- und Validierungsprüfungen.
- „Erfolgreiche Authentisierung bedeutet ausreichende Autorisierung.“ Nach der Identitätsprüfung müssen Zugriffe weiterhin auf Objekt-, Eigenschafts- und Funktionsebene geprüft werden.
- „Die OWASP Top 10 ist eine vollständige Checkliste.“ Sie ist eine Orientierung zu wichtigen Risiken, aber keine vollständige Spezifikation oder Einzelfall-Risikoanalyse.
- „Für jede API gelten dieselben Kontrollen und Grenzwerte.“ Kontrollen und Ressourcenlimits sind inkrementell und risikobasiert an Architektur und Einsatzkontext anzupassen.
Was die Geschäftsleitung tun sollte
Praxisempfehlung: Die folgenden Schritte sind technische Empfehlungen und werden hier nicht als allgemeine Rechtspflichten dargestellt.
- Verantwortlichkeiten für ein risikobasiertes API-Sicherheitsprogramm festlegen und interne sowie externe APIs in dessen Reichweite aufnehmen.
- Ein gepflegtes API-Inventar veranlassen und Risiken während Entwicklung, Bereitstellung, Integration und Betrieb ermitteln lassen.
- Für jede API eine risikobasierte Auswahl von Kontrollen zu Zugriff, Authentisierung, Validierung, Ressourcenverbrauch, Konfiguration und Fremd-APIs verlangen.
- Zusätzlich prüfen lassen, ob Verträge, interne Vorgaben oder anwendbare Spezialregelwerke konkrete Fristen, Grenzwerte oder Mindestmaßnahmen vorgeben.
Für die Geschäftsleitung
API-Sicherheit umfasst interne und externe Schnittstellen über Entwicklung und Betrieb hinweg. Zu entscheiden sind Verantwortlichkeiten, Risikoprioritäten und die zur jeweiligen Architektur passenden Kontrollen; ein Einzelprodukt oder eine Netzgrenze genügt nicht. Als Nachweis eignet sich insbesondere ein aktuelles API-Inventar. Konkrete verbindliche Anforderungen sind getrennt anhand der für die Organisation tatsächlich anwendbaren Vorgaben zu prüfen.
Quellen
- NIST SP 800-228 upd1: Guidelines for API Protection for Cloud-Native Systems, Abstract und Publikationsübersicht.
- NIST SP 800-228 upd1, Executive Summary sowie Abschnitte 1, 1.1 und 1.3.
- OWASP API Security Project, Abschnitt „What is API Security?“.
- OWASP API Security Top 10 – 2023, API1 bis API10.
- OWASP API Security Top 10 – Introduction, Einordnung und Grenzen.
