Black-Box Webservice-API-Penetrationstests sind eine dumme Idee

Warum die API das eigentliche Ziel ist

Moderne Anwendungen bestehen aus einem Frontend im Browser oder in der App und einem Backend, das die Arbeit macht. Dazwischen liegt die Webservice-API, die Anfragen entgegennimmt, prüft und beantwortet. Das Frontend können Sie hübsch finden oder nicht, sicherheitsrelevant ist es kaum. Ein Angreifer spricht direkt mit der API, an jeder Oberfläche vorbei.

Dazu kommt eine Entwicklung, die das Thema 2026 dringlicher macht. KI-gestützte Entwicklung erzeugt mehr Anwendungen und damit mehr Schnittstellen in kürzerer Zeit, und die Dokumentation hält damit noch seltener Schritt als früher. In unseren Tests stellen wir regelmäßig fest, dass die vorhandene Dokumentation der API zwei bis drei Versionen hinterherläuft. Jeder Endpunkt, der dabei durchrutscht, ist eine ungeprüfte Tür.

Black Box und White Box, die Begriffe sauber

Ein Black-Box-Test simuliert einen Angreifer ohne Vorwissen, der Tester erhält keine oder nur minimale Informationen über das Ziel. Ein White-Box-Test stellt dem Tester alle relevanten Informationen bereit, bei einer API sind das die Schnittstellenbeschreibung, Testzugänge und im Idealfall eine kurze Demonstration durch die Entwickler. Dazwischen liegt der Grey-Box-Test mit Teilwissen.

Für Infrastruktur-Tests kann ein Black-Box-Ansatz sinnvoll sein, etwa um zu prüfen, was ein externer Angreifer ohne jede Insiderkenntnis erreicht. Bei einer API kippt die Rechnung, und zwar aus einem Grund, der älter ist als jeder Computer.

Der Feind kennt das System

Auguste Kerckhoff hat 1883 formuliert, dass die Sicherheit eines Systems nicht von der Geheimhaltung seines Aufbaus abhängen darf. Claude Shannon hat es 1949 kürzer gesagt. Der Feind kennt das System. Wenn die Sicherheit Ihrer API darauf beruht, dass ein Angreifer die Endpunkte nicht kennt, haben Sie keine Sicherheit, Sie haben Security through Obscurity.

Ein echter Angreifer hat Zeit. Er liest den JavaScript-Code Ihres Frontends, beobachtet den Netzwerkverkehr Ihrer App über Wochen und findet die Endpunkte irgendwann. Ein Penetrationstester hat ein Budget. Jeder Tag, den er mit Reverse Engineering verbringt, ist ein Tag, an dem er nicht testet, was der Angreifer später ausnutzt. Sie bezahlen also dafür, dass Ihr Tester künstlich dumm gehalten wird, während der reale Gegner es nicht ist.

Was ein Black-Box-API-Test wirklich prüft

Die unbequeme Wahrheit steht in jedem Black-Box-Bericht zwischen den Zeilen. Geprüft wurde, was der Tester in der bezahlten Zeit gefunden hat. Nicht dokumentierte Endpunkte werden nicht geprüft, und erfahrungsgemäß sitzen genau dort die kritischen Lücken, der vergessene Debug-Endpunkt, die Alt-Version der Schnittstelle, der Admin-Pfad aus der Entwicklungszeit.

Dazu kommt die Art der Fehler, die bei APIs zählen. Die OWASP API Security Top 10 führt seit Jahren Berechtigungsfehler an der Spitze, allen voran Broken Object Level Authorization, also die Frage, ob Nutzer A die Daten von Nutzer B abrufen kann. Solche Fehler findet man nicht durch Herumraten an der Oberfläche. Man findet sie, indem man mit zwei verschiedenen Testzugängen systematisch prüft, wer was darf. Genau dafür braucht der Tester Dokumentation und Zugänge, also White Box.

Und was ist mit KI-Scannern?

Der Einwand kommt inzwischen in jedem zweiten Gespräch. Automatisierte Scanner und KI-Agenten finden Endpunkte doch von allein, wozu noch Dokumentation. Die Antwort steht im Ergebnis. Automatisierung skaliert die bekannten 80 Prozent der Angriffsfläche, schnell und billig, und wir setzen sie dafür selbst ein. Die restlichen 20 Prozent sind die Geschäftslogik, ob ein Bestellprozess sich austricksen lässt, ob ein Preis manipulierbar ist, ob Rollen sauber getrennt sind. Dafür muss man verstehen, was die API tun soll, und das steht in der Dokumentation, nicht im Netzwerkverkehr.

So sieht ein sauberer API-Test aus

Damit ein API-Test sein Geld wert ist, braucht der Tester vier Dinge, und keines davon ist aufwendig.

Was	Warum
Aktuelle Schnittstellenbeschreibung (OpenAPI, früher Swagger)	Vollständige Liste der Endpunkte und Parameter, nichts bleibt ungeprüft
Zwei Testzugänge mit unterschiedlichen Rollen	Berechtigungsprüfung nach OWASP, kann Nutzer A die Daten von Nutzer B sehen
Testumgebung oder abgestimmtes Zeitfenster	Tests ohne Risiko für den Produktivbetrieb
30 Minuten mit einem Entwickler	Die Demonstration klärt mehr als hundert Seiten Dokumentation, veraltete Stellen fallen sofort auf

Wenn die Dokumentation nicht aktuell ist, sagen Sie es vorher. Ein guter Tester plant dann einen Abgleich ein, statt die Lücken zu erraten. Auch das ist billiger als jeder Black-Box-Tag.

Unsere Empfehlung

Wenn Sie einen API-Test beauftragen, beauftragen Sie ihn als White-Box-Test und stellen Sie die vier Dinge aus der Tabelle bereit. Wenn ein Anbieter Ihnen den Black-Box-Test als das realistischere Szenario verkauft, fragen Sie ihn, wessen Zeit er Ihnen da berechnet. Und wenn Sie wissen wollen, was ein Angreifer ohne jedes Vorwissen von außen erreicht, ist das eine berechtigte Frage, aber eine andere Prüfung, nämlich ein externer Infrastruktur-Test. Beides zusammen ergibt ein Bild. Das eine durch das andere zu ersetzen ergibt eine Rechnung ohne Ergebnis.

Weiterführende NESEC-Beiträge

Warum Remote-Pentests die Zukunft sind, Ablauf und Zusammenarbeit

Warum ein Penetrationstest zu empfehlen ist, Einordnung und Testarten, Stand August 2026

Automatisierte Penetrationstests, was KI-Scanner leisten und was nicht

Checkliste, so finden Unternehmen den richtigen Pentest-Anbieter, die neun Auswahlkriterien