REST-APIs testen: was neben dem Happy Path geprüft gehört

Der Vertrag ist der Testplan

Eine OpenAPI-Beschreibung enthält alles, was für die formale Prüfung nötig ist: Pfade, Methoden, Parameter, Pflichtfelder, Typen, erlaubte Wertebereiche, Antwortschemata und die dokumentierten Statuscodes. Daraus lassen sich Testfälle nicht vollständig ableiten, aber die Randfälle: Für jedes Pflichtfeld gibt es einen Test ohne dieses Feld, für jeden Zahlenbereich einen Test an der Grenze, für jede Aufzählung einen Test mit einem Wert außerhalb.

Der zweite Nutzen ist die automatische Prüfung der Antwort gegen das Schema. Statt einzelne Felder zu vergleichen, prüft ihr, ob die gesamte Antwort dem hinterlegten Schema entspricht. Damit fallen auch die Änderungen auf, an die niemand gedacht hat: ein Feld, das plötzlich fehlt, ein Typ, der von Zahl auf Zeichenkette gewechselt ist, ein Nullwert an einer Stelle, die keinen zulässt.

Was der Vertrag nicht enthält, ist die Fachlichkeit. Dass ein Rabatt nie über hundert Prozent liegen darf, dass eine Frist nicht in der Vergangenheit enden kann, dass eine Stornierung nach dem Versand abgelehnt wird, all das steht in keinem Schema. Diese Fälle kommen aus dem Gespräch mit dem Fachbereich und aus den Verfahren des Testentwurfs, und sie sind der Teil, der die Schnittstelle wirklich absichert.

Statuscodes und Fehlerformate: wo die meisten Schnittstellen schludern

RFC 9110 legt die Bedeutung der Statuscodes fest, und die Abweichungen davon sind erstaunlich beständig. Die häufigste ist der Sammelcode 200 für alles, mit einem Feld im Rumpf, das den eigentlichen Fehler transportiert. Für Aufrufer ist das die unangenehmste Variante, weil jede Zwischenschicht, jeder Zwischenspeicher und jede Überwachung den Aufruf für erfolgreich hält.

Die zweite Abweichung betrifft die Unterscheidung von 401 und 403. Fehlt die Anmeldung oder ist der Token abgelaufen, gehört 401 zurück. Ist die Anmeldung in Ordnung, die Berechtigung aber nicht, gehört 403 zurück. Wer beide zusammenwirft, macht Aufrufern die Fehlerbehandlung unmöglich, denn nur im ersten Fall hilft ein neuer Token. Verwandt ist die Frage, ob eine fremde Ressource mit 403 oder mit 404 beantwortet wird. Beides ist vertretbar, 404 verrät weniger über die Existenz fremder Daten, aber es muss durchgängig gleich gehandhabt werden.

Die dritte Stelle ist die Unterscheidung zwischen kaputter Anfrage und unzulässigem Inhalt. Ein 400 sagt, dass die Anfrage formal nicht verarbeitbar war, etwa bei ungültigem JSON. Ein 422 sagt, dass sie formal in Ordnung war, der Inhalt aber gegen eine Regel verstößt. Für Aufrufer ist das ein wichtiger Unterschied, weil nur der zweite Fall ihnen sagt, dass sie die Daten korrigieren müssen und nicht ihren Aufruf.

Für den Rumpf der Fehlerantwort gibt es mit RFC 9457 ein festgelegtes Format. Es definiert die Felder type, status, title, detail und instance und schreibt den Medientyp application/problem+json vor. Wer das übernimmt, kann Fehlerfälle in der Testsammlung genauso hart zusichern wie Erfolgsfälle, und Aufrufer können auf den Typ reagieren, statt Zeichenketten zu vergleichen.

Berechtigungen sind der Bereich mit den meisten echten Funden

Die OWASP API Security Top 10 in der Fassung von 2023 führt an erster Stelle Broken Object Level Authorization, also die fehlende Prüfung, ob das anfragende Konto auf genau dieses Objekt zugreifen darf. Der Fall ist banal und trotzdem verbreitet: Eine Kennung steht in der URL, der Endpunkt prüft, ob überhaupt jemand angemeldet ist, und liefert dann aus. Wer die eigene Kennung um eins erhöht, bekommt fremde Daten.

Zwei weitere Punkte derselben Liste gehören in dieselbe Prüfung. Broken Object Property Level Authorization betrifft die Feldebene: Ein Konto darf ein Objekt sehen, aber nicht alle seine Felder, oder es darf es ändern, aber nicht das Feld, das den Preis oder die Rolle setzt. Broken Function Level Authorization betrifft ganze Endpunkte, typischerweise Verwaltungsfunktionen, die nur deshalb nicht auffallen, weil die Oberfläche den Knopf ausblendet.

Die praktische Umsetzung ist einfach und wird trotzdem selten gemacht: In jeder Sammlung liegen die Kennungen, die Konto A erzeugt hat, in Variablen. Für die Kreuzprüfung tauscht ihr nur den Token gegen den von Konto B und erwartet eine Ablehnung. Das lässt sich für alle Ressourcen in einem Durchlauf fahren, und es ist der Test, der in Erstprüfungen am häufigsten anschlägt.

Robustheit: Menge, Wiederholung und Nebenläufigkeit

Unbegrenzter Ressourcenverbrauch steht als eigener Punkt in der OWASP-Liste, und im Test bedeutet er zwei Fragen. Erstens: Was passiert bei einer Abfrage ohne Begrenzung, wenn dahinter hunderttausend Datensätze liegen? Eine Schnittstelle ohne verpflichtende Seitengröße lässt sich mit einem einzigen Aufruf in die Knie zwingen. Zweitens: Was passiert bei sehr vielen Aufrufen in kurzer Zeit? Wenn keine Begrenzung greift, ist das ein Befund, und wenn eine greift, gehört geprüft, ob sie mit 429 und einem Hinweis auf die Wartezeit antwortet.

Die Wiederholung schreibender Aufrufe ist der Fall, der im Betrieb sicher auftritt und im Test fast nie steht. Ein Aufrufer schickt eine Bestellung, das Netz stottert, er versucht es erneut. Wenn die Schnittstelle keinen Idempotenzschlüssel unterstützt, entstehen zwei Bestellungen, und dieser Fehler fällt niemandem in der Entwicklung auf, weil dort das Netz funktioniert. Der Test dafür ist ein Zweizeiler: denselben Aufruf zweimal schicken und zählen.

Nebenläufigkeit ist der dritte Bereich. Zwei Änderungen an derselben Ressource, die gleichzeitig eintreffen, dürfen sich nicht gegenseitig überschreiben. Der übliche Mechanismus dafür ist eine Versionsangabe über ETag und If-Match, sodass die zweite Änderung mit einem Konflikt abgelehnt wird. Wenn eure Schnittstelle das anbietet, gehört es geprüft. Wenn nicht, ist die stille Überschreibung ein Befund, den ihr an die Entwicklung meldet.

Was diese Prüfung nicht abdeckt

Sie ist kein Lasttest. Antwortzeiten unter normalen Bedingungen lassen sich in der Sammlung mit zusichern, aber die Frage, wie sich die Schnittstelle bei tausend gleichzeitigen Aufrufen verhält, braucht ein Werkzeug für Lastprofile und eine Umgebung, die der Produktion ähnelt. Wer beides vermischt, bekommt ungenaue Zahlen und langsame Testläufe.

Sie ist auch kein vollständiger Sicherheitstest. Die Prüfung entlang der OWASP-Liste deckt die Kategorien ab, die sich mit fachlichem Wissen und einem zweiten Konto finden lassen, und das ist der größere Teil der praktisch ausgenutzten Fälle. Was sie nicht abdeckt, sind Injection-Angriffe über verschachtelte Strukturen, Angriffe auf die Bibliotheken dahinter und Schwächen in der Infrastruktur. Dafür braucht es eine eigene Untersuchung mit anderen Werkzeugen.

Und sie ersetzt keine Vertragstests zwischen Diensten. Wenn drei andere Dienste eure Schnittstelle aufrufen, sagt eure eigene Sammlung nur, dass ihr eure Zusagen einhaltet, wie ihr sie verstanden habt. Ein Vertragstest, den der aufrufende Dienst beisteuert, sagt euch, was er tatsächlich erwartet, und das ist regelmäßig etwas anderes.