1. Inventar und Überblick

  • Alle APIs sind inventarisiert, auch alte Versionen, Test- und Schatten-APIs.
  • Jede API hat einen verantwortlichen Owner.
  • Die Spezifikation (etwa OpenAPI) ist aktuell und entspricht dem tatsächlichen Verhalten.
  • Veraltete Versionen und Test-Hosts sind abgeschaltet oder genauso geschützt wie die Produktion (Improper Inventory).
  • Datenflüsse zu Drittanbietern sind dokumentiert.

2. Authentifizierung

  • Zugriff nur mit etablierten Verfahren wie OAuth 2.0 oder OpenID Connect, keine selbst gebauten Login-Mechanismen.
  • Tokens haben eine kurze Lebensdauer und werden sauber erneuert und widerrufen.
  • Login, Passwort-Reset und Token-Ausstellung sind gegen Brute Force und Credential Stuffing geschützt.
  • JWT-Signaturen werden streng geprüft, unsichere Algorithmen wie none sind abgelehnt.

3. Autorisierung

  • Bei jedem Zugriff auf ein Objekt prüft der Server, ob genau dieser Nutzer es sehen oder ändern darf (BOLA).
  • Jede Funktion prüft serverseitig, ob die Rolle sie ausführen darf, auch Admin-Endpunkte (BFLA).
  • Lesbare und schreibbare Felder sind per Allowlist festgelegt, zusätzliche Felder werden abgelehnt (BOPLA, Mass Assignment).
  • Standard ist „verweigern“: Was nicht ausdrücklich erlaubt ist, ist verboten.

4. Eingaben, Ressourcen und Konfiguration

  • Jede Anfrage wird gegen ein Schema validiert, nur Erlaubtes passiert.
  • Es gibt Limits für Anfragen, Größen und Seitenumfänge (Rate Limiting, Pagination).
  • Ausgehende Anfragen an vom Nutzer angegebene URLs sind auf eine Allowlist beschränkt (SSRF).
  • TLS, CORS und Sicherheits-Header sind sauber gesetzt, Fehlermeldungen verraten keine internen Details (Security Misconfiguration).

5. Geschäftslogik

  • Sensible Abläufe wie Kauf, Buchung oder Registrierung sind gegen automatisierten Missbrauch geschützt.
  • Mehrstufige Abläufe werden serverseitig erzwungen, kein Schritt lässt sich überspringen.

6. Drittanbieter und Secrets

  • Antworten von Drittanbieter-APIs werden geprüft wie Nutzereingaben, Weiterleitungen nicht blind befolgt (Unsafe Consumption).
  • API-Schlüssel, Tokens und Zertifikate werden zentral verwaltet und regelmäßig rotiert.
  • Keine Secrets in Code, Git-Repositories oder Logs.

7. Testen und Nachweisen

  • Berechtigungen werden mit mehreren Test-Identitäten getestet, idealerweise bei jedem Release (CI/CD-Pipeline).
  • Ein Penetrationstest findet regelmäßig statt. DORA verlangt für Systeme, die kritische oder wichtige Funktionen unterstützen, mindestens jährliche Tests.
  • Fehlgeschlagene Anmeldungen, Berechtigungsfehler und Anomalien werden geloggt und überwacht.
  • Befunde sind mit Beleg dokumentiert, behoben und per Retest bestätigt.

Die Punkte aus den Abschnitten 3, 5 und 7 prüft Venedy automatisiert: KI-Agenten greifen Ihre API mit mehreren Identitäten an, und jeder Befund kommt mit HTTP-Beleg. So arbeitet Venedy

Häufige Fragen

Wie oft sollte man die Checkliste durchgehen?

Bei jeder neuen API und jeder größeren Änderung, dazu regelmäßig im Rahmen von Audits. Die Testpunkte aus Abschnitt 7 gehören idealerweise automatisiert in jedes Release.

Ersetzt die Checkliste einen Penetrationstest?

Nein. Die Checkliste zeigt, was abgesichert sein sollte. Ob die Absicherung tatsächlich hält, zeigt erst ein Test, der die API mit mehreren Identitäten angreift.

Worauf basiert die Checkliste?

Auf den OWASP API Security Top 10 (2023), dem OWASP REST Security Cheat Sheet und dem OWASP Application Security Verification Standard (ASVS), ergänzt um die Testpflicht aus DORA.

Quellen

Weiterlesen
SchutzAPI Security sicherstellen RisikenOWASP API Top 10 TestenAPI-Pentest