API-Sicherheit prüfen: von der Regel zum aussagekräftigen Test

Eine prüfbare Zusage statt eines allgemeinen Gütesiegels

„Die API ist sicher“ lässt offen, welche Daten, Benutzer und Abläufe gemeint sind. Eine brauchbare Zusage lautet etwa: „Ein normales Mitglied darf nur die Exporte seines Teams lesen; Entwürfe darf nur deren Ersteller bearbeiten; ein abgeschlossener Exportauftrag wird bei Wiederholung nicht noch einmal ausgeführt.“ Daraus lassen sich erwartete Ergebnisse ableiten.

Schreiben Sie zunächst die erlaubten Fälle auf. Manche Anwendungen erlauben Freigaben innerhalb eines Teams, andere nur persönliche Zugriffe. Ein Test, der pauschal jeden fremden Datensatz verbietet, wäre bei einer gewollten Teamfreigabe falsch. Danach definieren Sie die Gegenfälle: andere Identität, fehlende Rolle, anderer Mandant, unerlaubtes Feld, ungültiger Zustand oder widerrufener Zugang.

Für diese Aufgabe hilft eine Berechtigungsmatrix aus Aufrufer, Ressource und Aktion. OWASP Authorization Testing Automation beschreibt einen solchen Ansatz. Die Regeln müssen aus Ihrem Produktvertrag kommen; sie dürfen nicht lediglich das zufällige aktuelle Verhalten des Codes wiederholen.

Eine kleine eigene Umgebung mit kontrollierbaren Folgen

Verwenden Sie Testidentitäten und synthetische Datensätze, deren Herkunft Sie kennen. Eine geeignete Umgebung enthält die für die Frage wichtigen Schichten: beispielsweise Authentifizierung, tatsächlichen Anwendungscode, eine leere Testdatenbank und bei Cachefragen denselben Typ von Proxy. Für externe Dienste verwenden Sie Testmodi oder lokale Ersatzdienste. Reale Schlüssel und Kundendaten gehören nicht in diese Umgebung.

Legen Sie vor dem Start fest, welche Folgeaktionen möglich sind. Ein harmlos aussehender Aufruf kann E-Mails, Webhooks, Kosten oder Hintergrundjobs auslösen. Schließen Sie echte Empfänger aus, begrenzen Sie Mengen und Laufzeiten und verwenden Sie einen kontrollierten Ausgangszustand. Testläufe dürfen nicht versehentlich auf die Produktionsadresse umschalten.

Benennen Sie auch, wie Sie zurückkehren: Testsätze entfernen oder die isolierte Datenbank auf den bekannten Anfang zurücksetzen, Testschlüssel widerrufen und temporäre Freigaben schließen. Wird eine unerwartete externe Aktion sichtbar, stoppen Sie den Lauf und prüfen Sie die Umgebung, bevor weitere Fälle folgen. Eine absichtlich offene oder veränderte Gegenprobe gehört in eine getrennte Testkopie.

Beispiel: Team-Exporte prüfen

Für das folgende synthetische Beispiel existieren die Teams Blau und Grün. Lea und Nils sind normale Mitglieder von Blau, Mara verwaltet Blau, und Sam gehört zu Grün. Exporte dürfen alle Mitglieder ihres Teams lesen. Bearbeiten darf nur der Ersteller, solange der Export ein Entwurf ist. Nur eine Teamverwaltung darf einen fertigen Export löschen. Diese Regeln dienen allein dem Beispiel.

Die erwartete Ablehnung kann je nach API-Vertrag beispielsweise mit 403 oder einem verbergenden 404 erfolgen. Der Status allein reicht nicht: Eine Anwendung könnte nach einer unerlaubten Änderung einen Fehler zurückgeben. Prüfen Sie deshalb sowohl die Antwort als auch den gespeicherten Zustand und ausgelöste Folgearbeit. Ein Test muss außerdem sicherstellen, dass das benutzte Testobjekt tatsächlich existiert und der erlaubte Kontrollfall funktioniert; sonst kann ein versehentlich falscher Pfad eine erfolgreiche Ablehnung vortäuschen.

Die Fachartikel zu BOLA und IDOR, Rollenrechten, Feldrechten und Mandantentrennung erklären die jeweilige Durchsetzung. Hier verbinden Sie deren Regeln zu einem wiederholbaren Nachweis.

Die wichtigen Fälle im normalen Entwicklungsablauf erhalten

Fassen Sie Testidentitäten, Daten und erwartete Ergebnisse in lesbaren Fixtures zusammen. Der folgende JSON-Ausschnitt beschreibt einen einzelnen Testfall des Beispiels. Er wurde auf JSON-Syntax geprüft; er ist kein fertiger Testtreiber und führt keine HTTP-Anfrage aus.

{
  "case": "green-member-cannot-read-blue-export",
  "actor": "sam-green-member",
  "resource": "blue-export-01",
  "action": "read",
  "expected": {
    "decision": "deny",
    "containsExportData": false,
    "storedStateChanged": false,
    "jobsCreated": 0
  }
}

Der Testtreiber muss die echten serverseitigen Eintrittspunkte aufrufen, die vorbereitete Identität verwenden und die aufgeführten Wirkungen prüfen. Ein isolierter Test einer Hilfsfunktion ist nützlich, beweist aber nicht, dass jede Route diese Funktion verwendet. Ergänzen Sie deshalb passende Integrationstests dort, wo Routing, Datenzugriff und Folgeaktionen zusammenkommen. OWASP Authorization Regression Testing beschreibt das Beibehalten solcher Kontrollen bei Änderungen.

Wählen Sie Fälle nach möglichem Schaden und geändertem Verhalten. Neue Exportfunktionen brauchen andere Gegenfälle als eine reine Fehlertextkorrektur. Nach einem gefundenen Rechtefehler bleibt der passende Regressionstest erhalten. Wenn sich die fachliche Regel bewusst ändert, ändern Sie Erwartung und Begründung zusammen; schwächen Sie einen Test nicht lediglich deshalb ab, weil er einen Fehler aufdeckt.

Die Matrix um die tatsächlichen Anwendungskontrollen erweitern

Diese Auswahl ist kein vollständiger Testkatalog. Für eine systematische Erweiterung können Sie passende Anforderungen des OWASP Application Security Verification Standard mit genauer Versionsangabe heranziehen. Umfang und geforderte Tiefe müssen zur Anwendung passen. Eine pauschale Behauptung, „OWASP geprüft“ zu haben, verschleiert den tatsächlich untersuchten Gegenstand.

Wo eine öffentliche Antwortprobe hilft

Der API Security Check untersucht festgelegte öffentliche GET-/OPTIONS-Antworten und eine begrenzte GET-Fehlerprobe. Er kann damit etwa sichtbare CORS-, Methoden-, Header- oder Serverangaben einordnen. Er meldet keinen Nachweis für Ihre Rollenmatrix, Mandantentrennung oder Geschäftslogik. Er sucht auch nicht alle Endpunkte Ihrer Anwendung zusammen.

Verwenden Sie einen solchen Befund für die Frage, die er beantworten kann: Was war an diesem angegebenen Ziel unter den Bedingungen des Checks sichtbar? Halten Sie ihn von authentifizierten Integrationstests und von einer Prüfung Ihrer Konfiguration getrennt. Ein Ergebnis ohne sichtbare Auffälligkeit lässt die nicht geprüften Fragen offen. Der Leitfaden zu HTTP-Befunden hilft beim Lesen; Reports dokumentieren denselben begrenzten Messstand.

Ein Ergebnis dokumentieren, mit dem das Team weiterarbeiten kann

Ein brauchbarer Prüfvermerk nennt die Zusage, den geprüften Versionsstand, die Umgebung, die verwendeten synthetischen Rollen und die beobachtete Antwort samt Wirkung. Geheimnisse gehören nicht in den Bericht. Notieren Sie konkret, was ausgelassen wurde: etwa ein nicht verfügbarer Partner-Testmodus, eine nicht nachgestellte Browserpolitik oder ein noch nicht geprüftes Verhalten unter parallelen Prozessen.

Trennen Sie drei Ergebnisse: Die Erwartung ist belegt, die Erwartung wurde verletzt oder der Fall konnte nicht aussagekräftig geprüft werden. Ein nicht erreichbarer Endpunkt gehört zur dritten Gruppe. Eine gute Gesamtnote kann diesen Zustand nicht ersetzen. Beseitigen Sie einen konkreten Fehler und wiederholen Sie den betroffenen Fall sowie die eng verbundenen erlaubten Abläufe.

Wenn Sie eine Änderung zurücknehmen müssen, prüfen Sie auch den dadurch wieder geltenden Sicherheitszustand. Eine alte Version kann funktional zuverlässig sein und denselben bereits bekannten Rechtefehler zurückbringen. Wo der Schaden hoch ist oder wesentliche Fragen offenbleiben, planen Sie eine unabhängige fachliche Prüfung mit klarer Umgebung und Umfang. Die Entscheidung, ein Produkt freizugeben, beruht auf diesen Belegen und den verbleibenden Risiken; dieser Leitfaden stellt sie nicht automatisch aus.

Passende nächste Schritte