Die API-Security-Testing-Checkliste, gruppiert danach, wer prüft
Abgedeckt durch automatisierte funktionale Verifizierung
Das sind Verhaltensprüfungen: Reagiert die API korrekt auf eine Anfrage, die sie ablehnen sollte? Sie gehören in Ihre reguläre Suite und sollten bei jeder Änderung laufen.
Nicht authentifizierte Zugriffe werden abgelehnt. Jeder geschützte Endpunkt liefert ohne Zugangsdaten die korrekte Ablehnung statt Daten.
Die Autorisierung wird pro Objekt durchgesetzt. Nutzer A kann die Datensätze von Nutzer B nicht lesen oder verändern, indem im Pfad ein Bezeichner ausgetauscht wird. Das ist die am häufigsten ausgenutzte Schwachstelle in echten APIs – und eine schlichte Verhaltensprüfung.
Rollengrenzen halten. Eine Rolle mit reinem Lesezugriff kann nicht schreiben. Ein abgelaufenes oder widerrufenes Token wird abgelehnt.
Die Eingabevalidierung weist Werte außerhalb des zulässigen Bereichs ab. Grenzfälle bei jedem Parameter, auch bei denen, die niemand dokumentiert.
Fehlermeldungen geben keine Interna preis. Stacktraces, Query-Fragmente und interne Hostnamen tauchen in Antworten nicht auf.
Erfordert einen Scanner oder ein Spezialwerkzeug
Schwachstellen in Abhängigkeiten und Bibliotheken.
Injection-Klassen: SQL, Command, Template, Deserialisierung.
TLS-Konfiguration und Zertifikatsbehandlung.
Prüfung Ihres Stacks auf bekannte CVEs.
Erfordert einen Menschen
Missbrauch der Geschäftslogik. Eine negative Menge bestellen, einen Rabatt erneut einlösen, einen Schritt in einem Workflow überspringen, der eine feste Reihenfolge voraussetzt.
Threat Modeling und die Entscheidung, welche Daten tatsächlich sensibel sind.
Alles, was Kreativität dabei erfordert, wie jemand Ihr Produkt missbrauchen würde.
Der Punkt, den alle überspringen
Die Autorisierung auf Objektebene fehlt am häufigsten und lässt sich am einfachsten prüfen. Legen Sie zwei Accounts an, lassen Sie den einen einen Datensatz erstellen und versuchen Sie, ihn mit dem Token des anderen zu lesen. Kommen dabei Daten zurück, haben Sie die häufigste schwerwiegende API-Schwachstelle der Branche – gefunden mit einem einzigen Test.
Diesen Punkt zu automatisieren rechtfertigt den gesamten Aufwand, denn die Prüfung muss bei jedem neuen Endpunkt wiederholt werden – und daran denkt kein Mensch von allein.
Die automatisierbare Hälfte tatsächlich zum Laufen bringen
Generierte API-Pläne enthalten Kategorien für Autorisierung und Grenzfälle. Diese Prüfungen laufen damit direkt neben Ihrer funktionalen Abdeckung mit – statt als separate Sicherheitsübung, die niemand einplant.
Terminal
npm install -g @testsprite/testsprite-cli
testsprite setup
Das Dashboard deckt dasselbe ab, wenn Sie keine lokale Installation möchten, und der vollständige Befehlsumfang findet sich im CLI-Repository.
Die technischen Details stehen in der API-Testing-Dokumentation.
Die zwei Accounts, die Sie dauerhaft vorhalten sollten
Fast jeder Verhaltenspunkt auf dieser Liste braucht zwei Nutzer, und das Billigste, was Sie tun können, ist, in jeder Umgebung ein Paar Testaccounts dauerhaft vorzuhalten, statt sie pro Test neu anzulegen.
Machen Sie sie in genau den Punkten unterschiedlich, auf die es in Ihrem Produkt ankommt: unterschiedliche Eigentümer, unterschiedliche Rollen, sofern vorhanden, idealerweise unterschiedliche Organisationen. Dann wird aus jeder Autorisierungsprüfung ein zweizeiliger Test statt einer Setup-Übung – und dann schreibt sie auch wirklich jemand.
Die Variante, die scheitert, ist das Anlegen von Accounts innerhalb jedes Tests. Sie ist langsamer, sie hinterlässt Daten, und sie macht die Prüfung davon abhängig, dass Ihr Signup-Flow funktioniert – ein kaputtes Signup färbt dann jeden Berechtigungstest aus dem falschen Grund rot. Dauerhafte Accounts, einmal eingespielt, beseitigen all das.
Taktung je Gruppe
Verhaltensprüfungen bei jeder Änderung. Scanner nach Zeitplan und zum Release. Menschliche Prüfung, wenn sich das Bedrohungsmodell ändert – also wenn eine neue Art von Daten oder eine neue Art von Nutzer hinzukommt.
Verbinden Sie das Repository im Dashboard, dann starten die Läufe aus dem Deployment, das Sie ohnehin erzeugen – oder fügen Sie stattdessen einen Schritt in Ihren eigenen Workflow ein.
Wie TestSprite das automatisierbare Drittel abdeckt
Generierte API-Pläne enthalten Kategorien für Autorisierung und Grenzfälle. Die Verhaltenspunkte dieser Liste laufen damit neben Ihrer funktionalen Abdeckung mit – statt als separate Übung, die jemand einplanen muss.
Das heißt: Nicht authentifizierter Zugriff, Autorisierung auf Objektebene, Rollengrenzen, abgelaufene Token und Eingaben außerhalb des zulässigen Bereichs werden bei jeder Änderung gegen den laufenden Service geprüft, für jeden Endpunkt – auch für die, die letzte Woche dazugekommen sind. Auto-Authentication hält Sessions über einen ganzen Lauf hinweg aktiv, Dynamic Variables tragen Werte von Aufruf zu Aufruf, Dependency Chains leiten die Ausführungsreihenfolge daraus ab, was jeder Fall benötigt und erzeugt, und Auto-Cleanup entfernt genau das, was der Lauf angelegt hat.
Der Wert liegt in der Taktung, nicht in der Raffinesse. Diese Prüfungen sind nicht schwer zu schreiben; schwer ist es, beim vierzigsten Endpunkt noch an sie zu denken. Sie generieren und kontinuierlich laufen zu lassen schließt die am häufigsten ausgenutzte Lücke in echten APIs, ohne einen Prozess zu schaffen, an den sich jemand halten muss.
Ersetzt das einen Penetrationstest?
Nein. Es deckt die verhaltensbezogene Hälfte kontinuierlich ab. Das verkleinert, was ein Penetrationstest noch finden muss, und macht das teure Engagement wertvoller.
Scannt TestSprite nach Schwachstellen?
Nein. Es verifiziert Verhalten, einschließlich Autorisierung und Grenzfällen. Schwachstellen-Scanning ist ein anderes Instrument.
Wie oft sollten die Verhaltensprüfungen laufen?
Bei jeder Änderung. Ständig kommen neue Endpunkte dazu, und jeder braucht dieselbe Autorisierungsprüfung wie der davor.
Womit sollten wir anfangen?
Mit der Autorisierung auf Objektebene über jeden Endpunkt hinweg, der einen Bezeichner entgegennimmt. Höchste Trefferquote, geringster Aufwand.
Brauchen wir dafür ein Security-Team?
Für Threat Modeling und den Missbrauch der Geschäftslogik ja. Die Checklistenpunkte oben sind ganz normale Engineering-Arbeit.
Eine Checkliste ohne Verantwortliche ist ein Dokument.
Eine API-Security-Testing-Checkliste teilt sich in drei Bereiche: Verhaltensprüfungen, die Sie automatisieren und bei jeder Änderung laufen lassen, Scans nach Zeitplan und menschliches Urteilsvermögen zum Thema Missbrauch. Fangen Sie mit der Autorisierung auf Objektebene an – die häufigste schwerwiegende Schwachstelle, gefunden mit einem einzigen Test.