Die meisten Teams behandeln API-Sicherheit als ein Problem der Authentifizierung. Sie führen Token ein, prüfen sie auf jeder Route und halten die Sache damit für erledigt. Dann ändert ein Tester eine einzige Zahl in einer URL und liest die Rechnung eines fremden Kunden.

Genau in dieser Lücke zwischen “authentifiziert” und “autorisiert” liegen die meisten echten API-Vorfälle, und ein Scanner findet sie nicht zuverlässig. Ein automatisiertes Werkzeug sieht ein gültiges Token und eine 200er-Antwort und meldet Erfolg. Erst ein Mensch, der Ihre Geschäftsregeln versteht, bemerkt, dass in dieser Antwort die Daten einer anderen Person standen.

Der Kern der Sache: Die Authentifizierung belegt, wer da anfragt. Die Autorisierung entscheidet, was genau dieser Aufrufer sehen oder ändern darf, und sie muss für jedes Objekt, bei jeder Anfrage und in der Datenschicht durchgesetzt werden. Nahezu jede ernste API-Schwachstelle ist ein Versagen des zweiten Teils, während der erste einwandfrei funktioniert.

Fehlende Objektautorisierung, und warum sie dominiert

Die häufigste schwerwiegende API-Schwachstelle lässt sich zugleich am einfachsten beschreiben.

Ihr Endpunkt lautet /api/invoices/48213. Der Aufrufer ist authentifiziert, also holt der Handler Rechnung 48213 und gibt sie zurück. Niemand prüft, ob Rechnung 48213 überhaupt zu diesem Aufrufer gehört. Zahl ändern, fremde Rechnung erhalten. Die API hat sich genau so verhalten, wie sie geschrieben wurde; geschrieben war sie falsch.

Das skaliert schlecht für Sie und hervorragend für einen Angreifer. Fortlaufende Bezeichner erlauben es, Ihren gesamten Datenbestand mit einer einzigen Schleife abzugrasen. Der Wechsel auf nicht erratbare Bezeichner hilft ein wenig, ist aber keine Lösung, denn Bezeichner sickern über andere Endpunkte, über Exporte und über E-Mails nach außen.

Die Korrektur ist strukturell, nicht beiläufig. Die Eigentümerschaft muss in der Abfrage selbst geprüft werden: hole die Rechnung, die diesem Kunden gehört und diesen Bezeichner trägt, statt die Rechnung zu holen und darauf zu hoffen, dass später noch jemand nachsieht. Verankern Sie diese Prüfung in der Datenzugriffsschicht, damit sie nicht in einem neuen Controller vergessen wird, den in sechs Monaten jemand schreibt, der diesen Absatz nie gelesen hat.

Dasselbe Versagen betrifft Funktionen, nicht nur Objekte. Wenn ein administrativer Endpunkt allein dadurch geschützt ist, dass die Oberfläche für normale Nutzer nicht darauf verlinkt, dann ist er überhaupt nicht geschützt.

Die API-Schwachstellen, die tatsächlich auftauchen

Jenseits der Autorisierung macht eine Handvoll Probleme den Großteil der Befunde aus. Die OWASP API Security Top 10 sind hier die maßgebliche Referenz, und OWASP überarbeitet sie regelmäßig, also sehen Sie in der aktuellen Ausgabe nach statt in einer Zusammenfassung.

Mehr zurückgeben, als die Oberfläche zeigt. Ein Endpunkt liefert das vollständige Benutzerobjekt, weil das bequem war, und das Frontend zeigt davon drei Felder an. Die anderen zwölf, darunter das Token zum Zurücksetzen des Passworts und der interne Risikowert, stehen weiterhin in der Antwort. Wer den Netzwerk-Tab öffnet, hat sie. Serialisieren Sie bewusst und bauen Sie die Antwort aus benannten Feldern, statt ein Modell auszukippen.

Mass Assignment auf dem Hinweg. Das Spiegelbild desselben Fehlers. Ein Endpunkt zur Profilaktualisierung nimmt an, was auch immer ankommt, und schreibt es in den Datensatz, also ergänzt ein Aufrufer "role": "admin" und befördert sich selbst. Binden Sie ausdrücklich an eine Liste erlaubter Felder, statt den Request-Body im Ganzen zu übernehmen.

Unbegrenzter Verbrauch. Ohne Grenzen kann ein einzelner Aufrufer eine Million Datensätze pro Seite anfordern, teure Suchen in einer Schleife laufen lassen oder tausendfach Passwort-Resets auslösen. Das ist nicht nur eine Frage der Verfügbarkeit; wo jede Anfrage Sie Geld kostet, etwa bei einem Sprachmodell hinter Ihrem Endpunkt, ist es ein Angriff auf Ihre Rechnung. Ratenbegrenzungen gehören pro Konsument und pro Endpunkt gesetzt, wobei die teuren Operationen enger begrenzt werden als die billigen.

Bestandsaufnahme und Vertrauen in Dritte

Undokumentierte und vergessene Endpunkte. Version zwei ist live und dokumentiert, Version eins läuft noch mit der alten Autorisierungslogik, und eine Staging-API mit Produktionsdaten ist aus dem Internet erreichbar. Genau danach suchen Angreifer. Führen Sie ein Verzeichnis jeder ausgerollten API, jeder Version und jeder Umgebung, und nehmen Sie Dinge bewusst außer Betrieb statt durch Vernachlässigung.

Vertrauen in die Systeme, die Sie aufrufen. Ihre API konsumiert andere APIs, und deren Antworten landen in Ihrer Datenbank und in Ihrem Rendering. Prüfen Sie, was zurückkommt, statt einen Partner für sicher zu halten. Eine Antwort von außen ist Eingabe, mit allem, was das an Validierung nach sich zieht. Unser Leitfaden zur Integration fremder APIs behandelt die Zuverlässigkeitsseite derselben Beziehung.

Authentifizierung richtig aufsetzen

Die Authentifizierung bekommen die meisten Teams im Groben hin, deshalb geht es hier um die Details, die sie am Ende wieder zunichtemachen.

Verwenden Sie kurzlebige Zugriffstoken mit Refresh statt langlebiger Schlüssel, die nie ablaufen. Ein abgeflossenes Zugangsdatum, das ewig gilt, ist eine dauerhafte Kompromittierung; eines, das in fünfzehn Minuten verfällt, ist ein Vorfall mit absehbarem Ende.

Schneiden Sie Token eng zu. Ein Token für eine Reporting-Integration sollte keine Benutzer anlegen können. Scopes erlauben Ihnen, das zentral durchzusetzen, statt sich darauf zu verlassen, dass jeder einzelne Handler nachprüft.

Validieren Sie Token ordentlich, was vor allem heißt: Akzeptieren Sie nicht den Algorithmus, den das Token selbst behauptet. Legen Sie den erwarteten Signaturalgorithmus fest, prüfen Sie Aussteller und Zielgruppe und kontrollieren Sie die Gültigkeitsdauer. Es gibt Bibliotheken, die das von Haus aus tun; selbst gebaute Prüfroutinen sind der Ort, an dem die Fehler wohnen.

Rotieren Sie Zugangsdaten nach Plan und geben Sie Ihren Konsumenten einen Weg, ohne Ausfall zu wechseln, üblicherweise indem während der Umstellung zwei Schlüssel gültig sind. Wenn Rotation zu einer Störung führt, wird sie niemand durchführen.

Und schließlich: niemals Zugangsdaten in URLs. Query-Strings landen in Serverlogs, im Browserverlauf, in Proxy-Protokollen und in Referrer-Headern. Nutzen Sie Header.

Was ein Penetrationstest tatsächlich findet

Automatisiertes Scannen und manuelles Testen finden Unterschiedliches, und Sie brauchen beides aus unterschiedlichen Gründen.

Scanner sind stark bei bekannten verwundbaren Abhängigkeiten, fehlenden Sicherheits-Headern, TLS-Fehlkonfiguration und offensichtlicher Injection. Lassen Sie sie fortlaufend in Ihrer Pipeline laufen, denn sie sind billig und sie fangen Regressionen ab. Unsere Checkliste für das Server-Sicherheitsaudit zeigt, was dabei auf der Infrastrukturseite geprüft wird.

Was sie nicht können, ist über Ihr Geschäft nachdenken. Ein Tester stellt fest, dass ein Endpunkt für Rabattcodes mehrfach aufgerufen werden kann, um Rabatte zu stapeln, dass ein kostenpflichtiges Feature im Gratistarif erreichbar ist, wenn man die API direkt anspricht, oder dass die Stornierung einer bereits versandten Bestellung eine Rückerstattung ohne Bestandsprüfung auslöst. Das sind die Befunde, die echtes Geld kosten, und sie treten nur zutage, wenn jemand versteht, wozu Ihre API überhaupt da ist.

Verlangen Sie für eine API ausdrücklich Autorisierungstests über Rollen hinweg: Der Tester hält Zugangsdaten für zwei verschiedene Kunden und versucht systematisch, mit dem Token des einen an die Daten des anderen zu kommen. Diese eine Übung findet mehr als alles andere zusammen. Unser Überblick über die Arten von Penetrationstests erklärt, wie viel Zugang Sie einem Tester geben sollten, und Dokumentation samt Zugangsdaten liefert weit bessere Ergebnisse als ein Blindtest.

Beim Budget bewegt sich API-fokussiertes Testen typischerweise ab etwa £3,000 für eine kleine, gut dokumentierte API bis zu £15,000 oder mehr für eine große Angriffsfläche mit mehreren Rollen und Integrationen. Unser Leitfaden zu den Kosten von Penetrationstests schlüsselt auf, was diese Spanne treibt.

Genug protokollieren, um ermitteln zu können

Der Unterschied zwischen einem Vorfall und einer Katastrophe liegt meist darin, ob Sie rekonstruieren können, was passiert ist.

Protokollieren Sie Authentifizierungsereignisse, gescheiterte Autorisierungen und jede zustandsverändernde Operation samt Identität des Aufrufers, Zielobjekt und einem Korrelationsbezeichner. Gescheiterte Autorisierungen sind dabei Ihr Frühwarnsystem: Eine legitime Integration erzeugt fast keine, ein plötzlicher Schwall davon ist jemand, der sondiert.

Protokollieren Sie die sensiblen Werte selbst nicht. Token, Kartendaten und personenbezogene Daten in Logdateien machen aus einer eingedämmten Kompromittierung eine meldepflichtige.

Alarmieren Sie auf Muster statt auf Volumen. Ein einzelner Aufrufer, der über viele Objektbezeichner hinweg Autorisierungsfehler erzeugt, ist eine laufende Enumeration, und dafür lohnt es sich, jemanden zu wecken. Die Gesamtfehlerrate ist es nicht.

Halten Sie die Protokolle lange genug vor. Kompromittierungen werden häufig erst Wochen nach ihrem Beginn entdeckt, und dreißig Tage Logs sind oft zu kurz, um den Einstiegspunkt zu finden.

Testen Sie die API, die Sie wirklich ausgeliefert haben

Mecanik bietet Sicherheitstests für Anwendungen mit Schwerpunkt auf den Autorisierungs- und Geschäftslogikfehlern, die automatisierte Werkzeuge übersehen, einschließlich kontenübergreifender Tests mit echten Zugangsdaten über mehrere Rollen hinweg.

Wir arbeiten mit Ihrer Spezifikation und Ihrer Dokumentation, statt die Angriffsfläche zu erraten, was undokumentierte Endpunkte und Versions-Drift nebenbei zutage fördert. Wo die Arbeit bis in Infrastruktur- und Netzwerktests reicht, decken unsere Penetrationstest-Leistungen dieses Feld ab. Und wenn Ihre API hinter einer Webanwendung steht, zeigt unser Leitfaden zum Website-Sicherheitsaudit , wie die beiden Prüfungen ineinandergreifen. Und wenn Sie die API noch entwerfen, legt unser Leitfaden zu den Kosten der API-Entwicklung dar, wo Autorisierung, Ratenbegrenzung und Protokollierung im Bau hingehören, statt nachgerüstet zu werden.

Schicken Sie uns die Spezifikation und eine Beschreibung Ihrer Rollen, und wir sagen Ihnen, wo sich das Risiko ballt.

Siehe auch: WordPress gehackt: Schadsoftware sicher entfernen , DSGVO-technische Compliance für UK-Entwickler im Jahr 2026 , Cloudflare Zero Trust: ein Leitfaden für Enterprise-Zugriffssicherheit , Penetrationstests in Grossbritannien 2026 - Erwartungen .

Häufig gestellte Fragen

Was ist die häufigste Schwachstelle in der API-Sicherheit? Die fehlende Objektautorisierung, bei der ein authentifizierter Aufrufer an fremde Daten kommt, indem er einen Bezeichner in der Anfrage ändert. Die Authentifizierung arbeitet korrekt, aber nichts prüft, ob das angeforderte Objekt zu diesem Aufrufer gehört. Die Eigentümerschaft muss deshalb in der Abfrage selbst durchgesetzt werden.

Reichen API-Schlüssel als Absicherung aus? Für sich genommen nicht. Langlebige Schlüssel, die nie ablaufen, machen aus jedem Leck eine dauerhafte Kompromittierung. Nutzen Sie kurzlebige Zugriffstoken mit Refresh, schneiden Sie sie auf das zu, was der Konsument wirklich braucht, unterstützen Sie Rotation ohne Ausfall und senden Sie sie immer im Header statt in der URL.

Kann automatisiertes Scannen eine API absichern? Nein, auch wenn es sich lohnt, dauerhaft zu scannen. Scanner finden bekannte verwundbare Abhängigkeiten, fehlende Header und offensichtliche Injection. Über Ihre Geschäftsregeln können sie nicht nachdenken, also übersehen sie gestapelte Rabatte, im Gratistarif erreichbare Bezahlfunktionen und kontenübergreifenden Datenzugriff.

Was kostet ein API-Penetrationstest? Typischerweise ab etwa £3,000 für eine kleine, gut dokumentierte API bis zu £15,000 oder mehr für eine große Angriffsfläche mit mehreren Rollen und Integrationen. Die Kosten hängen an der Zahl der Endpunkte, der Zahl unterschiedlicher Rollen und daran, ob Dokumentation und Zugangsdaten bereitgestellt werden.

Was sollte eine API aus Sicherheitsgründen protokollieren? Authentifizierungsereignisse, gescheiterte Autorisierungen und jede zustandsverändernde Operation, jeweils mit Identität des Aufrufers, Zielobjekt und Korrelationsbezeichner. Token oder personenbezogene Daten gehören niemals ins Log. Alarmieren Sie, wenn ein einzelner Aufrufer über viele Bezeichner hinweg Autorisierungsfehler erzeugt, denn das deutet auf Enumeration hin.