💡 Key Takeaways
- Authentication and Authorization: The Foundation That Everyone Rushes Past
- Request Validation: Where Most Bugs Actually Live
- Response Validation: Trust, But Verify
- State Management and Idempotency: The Subtle Art of Consistency
Vor drei Jahren habe ich um 2 Uhr nachts beobachtet, wie eine Produktions-API spektakulär versagte, weil niemand getestet hatte, was passiert, wenn man ein Datumsfeld im Format "32/13/2021" sendet. Die Kaskade war auf die schlimmstmögliche Weise wunderschön: 47.000 fehlgeschlagene Transaktionen, wütende Kunden, die die Support-Kanäle überfluteten, und ein CEO, der Antworten wollte, die ich nicht hatte. Diese Nacht hat für immer geändert, wie ich API-Tests angehe.
💡 Wichtige Erkenntnisse
- Authentifizierung und Autorisierung: Die Grundlage, an der jeder vorbeieilt
- Anforderungsvalidierung: Wo die meisten Fehler tatsächlich liegen
- Antwortvalidierung: Vertrauen, aber überprüfen
- Statusverwaltung und Idempotenz: Die subtile Kunst der Konsistenz
Ich bin Sarah Chen und ich arbeite seit acht Jahren als QA-Automatisierungsingenieurin, die letzten fünf Jahre ausschließlich mit API-Tests für Fintech- und Gesundheitsplattformen. Ich habe alles getestet, von einfachen CRUD-Endpunkten bis hin zu komplexen Zahlungsabwicklungs-APIs, die täglich Millionen von Dollar verarbeiten. Was ich gelernt habe, ist Folgendes: Die meisten API-Ausfälle sind keine exotischen Randfälle – es sind vorhersehbare Probleme, die eine systematische Checkliste aufgefangen hätte.
Die Checkliste, die ich heute teile, ist genau die, die ich für jeden einzelnen Endpunkt, den ich teste, verwende. Sie hat mein Team im letzten Jahr vor mindestens einem Dutzend Produktionsvorfällen bewahrt und hat uns geholfen, eine Betriebszeit von 99,97 % über mehr als 230 API-Endpunkte aufrechtzuerhalten. Das ist keine Theorie – es ist eine bewährte Realität von jemandem, der mehrmals um 3 Uhr nachts gerufen wurde, als mir lieb ist.
Authentifizierung und Autorisierung: Die Grundlage, an der jeder vorbeieilt
Hier ist eine Statistik, die dich erschrecken sollte: Nach meiner Erfahrung bei der Prüfung von APIs in sieben verschiedenen Unternehmen hatten ungefähr 60 % mindestens einen Endpunkt mit fehlerhafter Autorisierungslogik. Nicht Authentifizierung – Autorisierung. Der Endpunkt überprüfte, ob du angemeldet warst, prüfte jedoch nicht ordnungsgemäß, ob du auf diese bestimmte Ressource zugreifen solltest.
Meine Checkliste zur Authentifizierung und Autorisierung beginnt mit den offensichtlichen, aber oft übersprungenen Grundlagen:
- Teste ohne Authentifizierungstoken – sollte 401 zurückgeben
- Teste mit einem abgelaufenen Token – sollte 401 zurückgeben, nicht 500
- Teste mit einem fehlerhaften Token – sollte 401 zurückgeben, nicht abstürzen
- Teste mit einem gültigen Token, aber falschen Berechtigungen – sollte 403 zurückgeben
- Teste mit einem Token für einen anderen Benutzer, der versucht, auf die Ressourcen eines anderen Benutzers zuzugreifen
Der letzte Punkt wird spannend. Ich habe einmal einen Endpunkt gefunden, bei dem du die Zahlungshistorie eines Benutzers abrufen konntest, indem du einfach die Benutzer-ID in der URL ändertes, obwohl du dich als ein anderer Benutzer authentifiziert hattest. Der Endpunkt überprüfte, ob du angemeldet warst, aber überprüfte niemals, ob die angeforderte Benutzer-ID mit deiner authentifizierten Benutzer-ID übereinstimmte. Dies wird als Unsichere direkte Objektverweisung (IDOR) bezeichnet und ist schockierend häufig.
Ich teste auch explizit die Token-Aktualisierungsflüsse. Was passiert, wenn ein Token während einer Anfrage abläuft? Behandelt deine API das elegant oder versetzt es den Client in einen merkwürdigen Status? Ich habe Systeme gesehen, bei denen ein abgelaufenes Token während einer POST-Anfrage einen 401 zurückgab, die Daten jedoch weiterhin teilweise in die Datenbank geschrieben wurden. Das ist ein Albtraum für die Datenkonsistenz.
Für APIs, die API-Schlüssel anstelle von Tokens verwenden, überprüfe ich, ob die Schlüsselrotation korrekt funktioniert. Kannst du einen neuen Schlüssel generieren? Funktioniert der alte Schlüssel sofort nicht mehr oder gibt es eine Karenzzeit? Ist diese Karenzzeit dokumentiert? Ich habe einmal mit einer API gearbeitet, bei der die Rotationsschlüssel eine 24-stündige Überlappungszeit hatten, von der niemand wusste, was zu Sicherheitsprüfungsfehlern führte.
Die Autorisierungsmatrix ist meine geheime Waffe hier. Ich erstelle eine Tabelle mit jedem Endpunkt auf einer Achse und jeder Benutzerrolle auf der anderen. Dann teste ich systematisch jede Kombination. Es ist mühsam, aber sie hat in 100 % der Projekte, in denen ich sie angewendet habe, Autorisierungsfehler erkannt. Ja, 100 %. Das ist keine Übertreibung – jedes einzelne Projekt hatte mindestens einen Endpunkt, bei dem die Autorisierungslogik für mindestens eine Rolle falsch war.
Anforderungsvalidierung: Wo die meisten Fehler tatsächlich liegen
Wenn ich schätzen müsste, wo 70 % der API-Fehler ihren Ursprung haben, wäre es in der Anforderungsvalidierung. Entwickler sind optimistische Wesen – sie schreiben Code in der Annahme, dass die Eingaben vernünftig sein werden. Aber das Internet ist nicht vernünftig, und das sind die Systeme, die deine APIs aufrufen, auch nicht.
Meine Checkliste zur Anforderungsvalidierung ist erschöpfend, weil sie es sein muss:
- Unterstütze einen völlig leeren Anforderungstext – was passiert?
- Unterstütze null für jedes erforderliche Feld einzeln
- Unterstütze leere Strings für Stringfelder
- Unterstütze nur Leerzeichen enthaltende Strings
- Unterstütze Strings, die um ein Zeichen zu lang für alle Längenbeschränkungen sind
- Unterstütze Strings, die 1000x zu lang sind
- Unterstütze negative Zahlen für Felder, die positive Ganzzahlen erwarten
- Unterstütze null für Felder, bei denen 0 ungültig sein könnte
- Unterstütze Dezimalzahlen für Ganzzahlfelder
- Unterstütze extrem große Zahlen (test für Ganzzahlenüberlauf)
- Unterstütze extrem kleine Zahlen (test für Unterlauf)
- Unterstütze Sonderzeichen in Stringfeldern: Anführungszeichen, Rückwärtsschritte, Nullbytes, Unicode
- Unterstütze SQL-Injection-Versuche (auch wenn du ein ORM verwendest)
- Unterstütze XSS-Payloads in Stringfeldern
- Unterstütze nicht übereinstimmende Datentypen (String, wenn eine Zahl erwartet wird usw.)
Ich weiß, was du denkst: "Sarah, das ist verrückt. Niemand hat Zeit dafür." Aber – ich habe diese gesamte Checkliste automatisiert. Ich habe einen Testdatengenerator, der all diese Variationen automatisch produziert. Der anfängliche Aufbau hat mich etwa zwei Wochen gekostet, aber jetzt kann ich dieses gesamte Paket in ungefähr 15 Minuten gegen einen neuen Endpunkt laufen lassen.
Der Ertrag ist real. Letzten Monat hat diese Checkliste einen Endpunkt entdeckt, der den gesamten API-Server zum Absturz bringen würde, wenn du einen String sendest, der länger als 65.535 Zeichen ist. Der Entwickler hatte angenommen, die Datenbank würde die Längenvalidierung übernehmen, aber die Datenbank war so konfiguriert, dass sie stillschweigend kürzte, und der Anwendungscode versuchte, den gesamten String in einen Puffer fester Größe zu protokollieren. Boom – Segmentierungsfehler, Serverausfall.
Für Daten- und Zeitfelder habe ich eine spezielle Unter-Checkliste, weil diese einzigartig schrecklich sind:
- Unterstütze Daten in verschiedenen Formaten (ISO 8601, MM/DD/YYYY, DD/MM/YYYY usw.)
- Unterstütze ungültige Daten (30. Februar, Monat 13, Tag 32)
- Unterstütze Daten aus der fernen Vergangenheit (Jahr 1900, Jahr 1)
- Unterstütze Daten aus der fernen Zukunft (Jahr 2100, Jahr 9999)
- Unterstütze Daten mit unterschiedlichen Zeitzonenoffsets
- Unterstütze Daten während der Umstellung auf Sommerzeit
- Unterstütze Zeitstempel mit Millisekunden, Mikrosekunden, Nanosekunden
Dieses Thema der Sommerzeit hat mich zweimal erwischt. Zweimal! Du würdest denken, ich würde lernen, aber es ist so ein merkwürdiger Randfall, dass es leicht ist, es zu vergessen. Ich habe jetzt einen speziellen Test, der Transaktionen um 2 Uhr nachts am Tag, an dem die Uhren umgestellt werden, ausführt, denn genau dann geschehen die seltsamen Dinge.
Antwortvalidierung: Vertrauen, aber überprüfen
Die meisten Tester konzentrieren sich stark auf Anfragen und werfen kaum einen Blick auf die Antworten. Das ist falsch. Die Antworten deiner API sind ihr Vertrag mit der Welt. Wenn sie inkonsistent, unvollständig oder falsch sind, hast du diesen Vertrag gebrochen.
| Testkategorie | Häufiger Fehlerpunkt | Erwartete Antwort | Was tatsächlich passiert |
|---|---|---|---|
| Kein Authentifizierungstoken | Fehlende Fehlerbehandlung | 401 Nicht autorisiert | 500 Interner Serverfehler oder offengelegte Daten |
| Abgelaufenes Token | Token-Validierungslogik | 401 Nicht autorisiert | 500-Fehler oder stummer Fehler |
| Fehlerhaftes Token | Eingabevalidierung | 401 Nicht autorisiert | Anwendung abstürzen oder Stack-Trace offengelegt |
| Gültiges Token, falsche Berechtigungen | Autorisierungsprüfungen | 403 Verboten | 200 OK mit unautorisierter Datenzugriff |
| Ungültiges Datumsformat | Eingabesanierung | 400 Falsche Anfrage | Transaktionskaskade fehlschlagen |
Meine Checkliste zur Antwortvalidierung umfasst:
- Überprüfe, ob der Antwortstatuscode mit dem dokumentierten Verhalten übereinstimmt
- Überprüfe, ob der Content-Type-Header der Antwort korrekt ist
- Überprüfe, ob die Struktur des Antwortinhalts mit dem Schema übereinstimmt
- Überprüfe, ob alle dokumentierten Felder vorhanden sind
- Überprüfe, ob keine undokumentierten Felder vorhanden sind (das ist wichtig für das API-Versioning)
- Überprüfe, ob die Datentypen der Felder mit der Dokumentation übereinstimmen
- Überprüfe, ob die Feldwerte innerhalb der dokumentierten Bereiche liegen
- Überprüfe, ob Zeitstempel in der richtigen Zeitzone sind
- Überprüfe, ob die Paginierungsmetadaten korrekt und konsistent sind
- Überprüfe, ob Fehlermeldungen hilfreiche Informationen enthalten
- Überprüfe, ob Fehlermeldungen Fehlercodes für die programmgemäße Handhabung enthalten
Der vorletzte Punkt über Fehlermeldungen ist entscheidend. Ich habe APIs gesehen, die einfach "Fehler" als gesamte Fehlermeldung zurückgeben. Das ist nutzlos. Eine gute Fehlermeldung sagt dir, was schiefgelaufen ist, warum es schiefgelaufen ist und idealerweise, was du tun kannst, um es zu beheben. Vergleiche diese beiden Fehlermeldungen:
Schlecht: {"error": "Ungültige Anfrage"}
Gut: {"error": "Ungültige Anfrage", "message": "Feld 'email' ist erforderlich, wurde jedoch nicht angegeben", "code": "MISSING_REQUIRED_FIELD", "field": "email"}
Die...