Betriebsstatus
API-Sicherheit · Orientierung
API-Sicherheit: Zugriffe, Daten und Abläufe gezielt absichern
Eine sichere API muss bei jeder Anfrage entscheiden, wer welche Daten lesen oder verändern darf, welche Eingaben zulässig sind und wie viel Arbeit der Aufruf auslösen darf. HTTPS und passende Header gehören dazu. Ob ein Kunde fremde Rechnungen abrufen kann oder ein wiederholter Auftrag doppelt ausgeführt wird, entscheidet jedoch die Anwendung.
Beginnen Sie deshalb bei Ihrer konkreten Aufgabe: einen Befund verstehen, einen Zugang entwerfen, einen Fehler beheben oder den laufenden Betrieb absichern. Dieser Ratgeber verbindet die dafür nötigen Grundlagen mit praktischen Anleitungen für Entwickler und technische Betreiber öffentlich erreichbarer HTTP-APIs. Auch ein öffentlich erreichbarer Endpunkt kann eine Anmeldung verlangen.
Auf dieser Seite
Zuerst festhalten, wem die API was glauben darf
Eine API ist eine Schnittstelle, über die Programme Daten austauschen und Funktionen auslösen. Bei HTTP gehören dazu eine Adresse, eine Methode wie GET oder POST, Anfrageheader und gegebenenfalls ein Inhalt. Die Antwort enthält einen Status, Header und möglicherweise Daten. Ein Endpunkt bezeichnet hier eine konkrete erreichbare API-Adresse; dieselbe Adresse kann je nach Methode eine andere Aufgabe haben.
Die erste Sicherheitsfrage lautet: Welche Informationen stammen von außen, und welche Entscheidungen dürfen sie beeinflussen? Eine im Browser mitgesendete Kunden-ID ist zunächst nur eine Behauptung. Ein gültiges Token kann die Identität belegen, ohne dieser Identität Zugriff auf jeden Datensatz zu geben. Eine signierte Nachricht eines Partners kann echt sein und trotzdem doppelt oder verspätet eintreffen.
Skizzieren Sie für einen wichtigen Ablauf die Stationen: Client, Gateway oder Reverse-Proxy, Anwendung, Datenbank, Hintergrundauftrag und externer Dienst. Markieren Sie, wo Daten oder Identitäten zwischen Verantwortungsbereichen wechseln. Das ist eine Vertrauensgrenze: An dieser Stelle muss die empfangende Seite entscheiden, was sie selbst prüft und auf welche eng begrenzte Zusage sie sich verlässt. Eine solche Betrachtung ist ein Einstieg in Threat Modeling, also das systematische Erkennen und Behandeln möglicher Fehl- und Missbrauchsfälle.
Ein synthetisches Beispiel: Ein Team darf über seine API einen Export anfordern. Die Anwendung muss den Teamzugang prüfen, die erlaubten Daten auswählen, Aufwand und Parallelität begrenzen und dem Hintergrundauftrag den richtigen Teamkontext mitgeben. Der spätere Download braucht erneut eine passende Zugangsentscheidung. Eine einzige Prüfung am ersten Formular löst diese Kette nicht.
Synthetisches Beispiel · kein Prüfergebnis
Team-Export: Zugang und Kontext durch die Kette tragen
Ein Mitglied von Team Blau fordert einen Export an. Die Ausgabe darf nur die für Team Blau freigegebenen Datensätze enthalten.
- Client → API: Teamzugang prüfen
Die mitgesendete Team-ID ist zunächst eine Behauptung. Die Anwendung entscheidet, ob der Aufrufer Zugang zu diesem Team hat.
- API → Auftrag: Daten und Aufwand begrenzen
Die Anwendung wählt die erlaubten Teamdaten aus und begrenzt Aufwand und Parallelität des Exports.
- Auftrag → Hintergrundjob: Teamkontext erhalten
Die Übergabe muss den richtigen Teamkontext mitführen. Der Job verarbeitet die dem Auftrag zugeordneten, erlaubten Teamdaten.
- Hintergrundjob → Download: Zugang erneut entscheiden
Der Export bleibt seinem Team zugeordnet. Beim Download entscheidet die Anwendung erneut, ob dieser Aufrufer diesen Export erhalten darf.
Eine Prüfung am ersten Formular deckt die späteren Übergänge nicht ab. Teamkontext, erlaubte Daten und zulässige Aktion gehören an jede betroffene Vertrauensgrenze.
Die passende Anleitung für Ihre Aufgabe
Sie müssen die Serie nicht der Reihe nach lesen. Für eine neue API folgt die Reihenfolge dem Weg einer Anfrage und dem späteren Betrieb. Bei einem konkreten Fehler wählen Sie direkt die betroffene Aufgabe.
Bei schmaler Ansicht können Sie die Tabelle seitlich scrollen.
| Ihre Aufgabe | Einstieg und anschließende Vertiefung |
|---|---|
| Zugang für Browser, Dienste oder fremde Anwendungen auswählen | Authentifizierung entscheiden, danach API-Schlüssel oder OAuth und OIDC; für die API-seitige Tokenprüfung JWT validieren. |
| Fremde Daten und unerlaubte Aktionen verhindern | Objektzugriff: BOLA und IDOR, Rollen und Funktionsrechte, Feldrechte und Mass Assignment, bei mehreren Organisationen Mandantentrennung. |
| Anfragen sauber verarbeiten und verständlich antworten | Eingaben validieren, Fehler und Statuscodes sowie HTTP-Befunde richtig einordnen. |
| API aus dem Browser verwenden | CORS konfigurieren, CORS-Fehler untersuchen und Cookies und CSRF. Konkrete Umsetzungen: nginx und Express. |
| Kosten, Last und unerwünschte Geschäftsabläufe begrenzen | Rate-Limits und Ressourcenbudgets, Retries und Idempotenz, Geschäftslogik absichern. |
| Daten und Ereignisse mit anderen Diensten austauschen | SSRF bei Ziel-URLs verhindern, externe API-Antworten sicher verarbeiten und Webhooks prüfen und verarbeiten. |
| Architektur und laufenden Betrieb beherrschen | Gateway-Verantwortung, Inventar und Versionierung, Logging, Überwachung und Reaktion. |
| GraphQL mit seinen besonderen Ausführungsmöglichkeiten einsetzen | GraphQL absichern: Resolver- und Feldrechte, Abfragekosten und Fehlerverhalten. |
| Nach einer Änderung belastbar prüfen | Eigene API-Sicherheit prüfen verbindet erwartetes Verhalten, eigene Testdaten und aussagekräftige Gegenfälle. |
Für Transport und gemeinsame Browsergrundlagen nutzen Sie die bestehenden Anleitungen zu TLS-Zertifikaten, HSTS, Cache-Control und Cross-Origin-Headern. Sie ergänzen die Anwendungskontrollen; keine dieser Maßnahmen ersetzt die anderen.
Welche Art von Nachweis beantwortet Ihre Frage?
Authentifizierung prüft eine Identität oder einen Zugangsnachweis. Autorisierung entscheidet, was dieser Aufrufer im aktuellen Kontext tun darf. Geschäftsregeln bestimmen zusätzlich, welche Handlung in einem Ablauf überhaupt noch zulässig ist. Diese Trennung hilft bei der Auswahl der Prüfung.
Bei schmaler Ansicht können Sie die Tabelle seitlich scrollen.
| Frage | Dafür geeigneter Beleg | Was daraus noch nicht folgt |
|---|---|---|
| Welche Header liefert dieser Endpunkt? | Antwort auf eine benannte Anfrage mit Zeitpunkt und Kontext. | Andere Pfade, Methoden, angemeldete Nutzer oder spätere Antworten sehen genauso aus. |
| Kann eine fremde Organisation diesen Datensatz lesen? | Eigene Testidentitäten, bekannte Beispieldaten, erwartete Rechte und tatsächlicher Daten-/Zustandsabgleich. | Ein verweigerter Einzelabruf beweist alle Listen, Exporte und Hintergrundjobs. |
| Wird ein Auftrag trotz Wiederholung nur einmal wirksam? | Kontrollierte Wiederholung und Parallelität in einer isolierten Umgebung; gespeicherter Zustand und ausgelöste Folgearbeit. | Ein erfolgreicher HTTP-Status beweist die fachliche Wirkung. |
| Wird ein Missbrauchsversuch bemerkt? | Definiertes Testereignis, sichtbares Signal und nachvollziehbarer Bearbeitungsweg im eigenen Betrieb. | Ein vorhandener Logeintrag wird auch überwacht oder führt zu einer Reaktion. |
Die OWASP API Security Top 10, Ausgabe 2023, helfen, wichtige Risikogruppen zu erkennen: unter anderem Identitäten, Rechte, Ressourcen, Geschäftsabläufe, externe Dienste und veraltete API-Bestände. Sie sind keine vollständige Testanleitung und keine rechtliche Norm. Wählen Sie Kontrollen anhand Ihrer Daten, Abläufe und möglichen Schäden; das Abhaken von zehn Überschriften genügt nicht.
Wenn der Browser eine Antwort nicht lesen darf
CORS regelt, ob Browsercode eine Antwort einer anderen Origin verwenden darf. Eine Origin besteht aus Schema, Host und Port. Ein Browserfehler sagt nicht automatisch, dass der Server keine Anfrage erhalten oder keine Aktion ausgeführt hat. Manche Anfragen haben einen vorgeschalteten OPTIONS-Preflight; andere werden zunächst gesendet und ihre Antwort anschließend vom Browser zurückgehalten.
Prüfen Sie deshalb zuerst die tatsächlich aufrufende Origin, den Credentials-Modus, die Preflightantwort und die eigentliche Antwort. CORS ist keine Anmeldung und keine serverseitige Berechtigungskontrolle. Auch eine passende CORS-Freigabe sagt nichts über Objekt- oder Mandantenrechte. Die CORS-Diagnose führt diese Fälle auseinander; Cookies und CSRF behandelt den Schutz vor ungewollten Aktionen. Die technische Grundlage liefert der Fetch Standard.
Wenn ein Header fehlt oder ein Serverhinweis auftaucht
Betrachten Sie die konkrete Antwortart. Eine JSON-Antwort, ein Dateidownload und die HTML-Anmeldeseite vor einer API brauchen nicht dieselbe Einordnung. Content-Type sollte zum ausgelieferten Inhalt passen. Cache-Regeln müssen unterscheiden, ob die Daten allgemein öffentlich oder nutzerbezogen sind. Ein angekündigtes DELETE ist noch kein Beweis, dass Unberechtigte löschen können.
Auch eine im Header genannte Produktversion ist zunächst eine Selbstauskunft einer beteiligten Schicht. Ob ein bekanntes Sicherheitsproblem tatsächlich vorliegt, klären Sie mit installiertem Paketstand, Herstellerhinweisen und Konfiguration. Der Leseschlüssel für HTTP-Befunde erklärt den Weg vom Signal zur passenden Prüfung. Er führt zu den vorhandenen Web-Grundlagen, ohne jede JSON-API wie eine HTML-Seite zu behandeln.
Wenn Fehler, Wartezeiten oder doppelte Vorgänge auftreten
Ein Stacktrace in einer Antwort ist ein konkreter Anlass, den Fehlerpfad zu korrigieren. Eine unauffällige Antwort deckt aber nicht sämtliche Fehlerpfade ab. Bei 401, 403 oder einer HTML-Antwort statt JSON helfen Statuscodes und sichere Fehlerantworten, die Ursache im richtigen Teil der Kette zu suchen.
429 Too Many Requests meldet eine Begrenzung; ein vorhandener oder fehlender Limit-Header belegt weder flächendeckenden Schutz noch dessen Abwesenheit. Für die Betreiberentscheidung lesen Sie Rate-Limits. Wenn ein Client nach einem Timeout erneut senden soll, klären Sie zuvor den ungewissen Ausgang und die Idempotenz des Vorgangs. Sonst kann eine gut gemeinte Wiederholung zusätzliche Arbeit oder eine doppelte Aktion auslösen.
Aus der offenen Frage einen überprüfbaren nächsten Schritt machen
Notieren Sie für einen Befund URL, Methode, Zeitpunkt, erwartete Funktion und Anmeldezustand. Bei Browserproblemen gehören Origin und Credentials-Kontext dazu. Entfernen Sie Schlüssel, Tokens und vertrauliche Inhalte aus Unterlagen, die Sie weitergeben. Formulieren Sie anschließend eine überprüfbare Erwartung, etwa: „Ein Mitglied von Team Blau sieht im Export ausschließlich die für Team Blau freigegebenen Datensätze.“
Für ausgewählte öffentliche Antwortmerkmale eines eigenen oder ausdrücklich zur Prüfung freigegebenen Endpunkts kann der API Security Check einen begrenzten Ausgangsbefund liefern. Lesen Sie den Prüfumfang vor dem Start. Der Check sendet festgelegte GET-/OPTIONS-Anfragen und eine begrenzte GET-Fehlerprobe. Er prüft weder angemeldete Rollen noch Objektberechtigungen, Geschäftslogik oder tatsächliche Rate-Limit-Durchsetzung. Aus einer guten Note wird keine Sicherheitsfreigabe; ein nicht erhobener Teil gilt nicht als bestanden.
Ein Report dokumentiert den vorhandenen Messstand und erweitert die Prüfung nicht. Änderungen beurteilen Sie anhand geeigneter neuer Belege; ein Download ist keine neue Messung. Für Anwendungskontrollen bietet der Leitfaden Eigene API-Sicherheit prüfen einen Entwicklungs- und Testweg.
Eine Scanner-API wäre dagegen ein programmatischer Zugang, mit dem andere Software Wolf-Agents-Prüfungen anstößt oder Ergebnisse abruft. Ein solcher Zugang wird hier nicht angeboten. Die Checkübersicht unterscheidet die vorhandenen Web-, E-Mail- und API-Prüfwege.
Quellen und Einordnung
Die Einordnung stützt sich auf die OWASP API Security Top 10 2023, OWASP Threat Modeling, die HTTP-Semantik in RFC 9110 und den Fetch Standard. Quellenprüfung: 27. September 2026. Die verlinkten Fachartikel benennen zusätzliche Quellen und die Grenzen ihrer Beispiele. Dieser Ratgeber ist kein Prüfergebnis Ihrer Anwendung.