Wie der Angriff funktioniert

Ein Secret (API-Key, Bearer-Token, Datenbank-Connection-String) authentifiziert einen Aufrufer gegenüber einer API. Wer das Secret kennt, gilt als legitimer Aufrufer - es ist also wie ein Passwort zu behandeln.

Geleakt wird es typischerweise über vier Kanäle:

  • Hartkodierung im ausgelieferten Code: insbesondere in Mobile-Apps oder JavaScript-Frontends, wo das Secret durch Dekompilieren bzw. im Browser auslesbar ist.
  • Einchecken in Versionskontrolle: vor allem in öffentliche Repositories, wo es auch nach dem Löschen über die Git-Historie auffindbar bleibt.
  • Logs: laut OWASP REST Security werden Credentials in der URL in Webserver-Logs erfasst, und das Logging Cheat Sheet zählt Access Tokens, Passwörter, Connection-Strings und Encryption-Keys explizit zu den Daten, die niemals direkt geloggt werden dürfen.
  • URL/Query-Parameter: Secrets in der URL landen in Server-Logs, Proxy-Logs, Browser-History und Referer-Headern.

Weil ein Secret den Aufrufer wie ein Passwort ausweist, kann jeder Finder die API mit den Rechten des legitimen Inhabers ansprechen, bis das Secret rotiert oder widerrufen wird.

1. AusgangslageKey oder Token in Client-Code, Repo, Log oder URL
→
2. AngriffAngreifer findet das Secret
→
3. ErgebnisVoller API-Zugriff mit fremdem Schlüssel

Offengelegte Schlüssel geben Angreifern direkten API-Zugriff.

Beispiel

API-Key in URL vs. Header (OWASP)
NICHT OK:
GET https://example.com/controller/123/action?apiKey=a53f435643de32

OK (Secret im Header):
GET https://example.com/resourceCollection/123/action
Authorization: Bearer a53f435643de32

Auswirkung

Ein offengelegtes Secret verschafft Angreifern unmittelbar die Zugriffsrechte des legitimen Inhabers auf die API. Das schließt Datenzugriff, Datenmanipulation oder kostenpflichtige Nutzung gebührenpflichtiger Dienste auf Rechnung des Opfers ein.

In URLs oder Logs gespeicherte Credentials sind laut OWASP gerade deshalb "intrinsically valuable", weil sie in Webserver-Logs erfasst werden und dort persistieren.

Solange das Secret nicht rotiert oder widerrufen ist, bleibt der unautorisierte Zugriff bestehen. Regelmäßige Rotation begrenzt diese Zeitspanne - laut OWASP wären etwa gestohlene Datenbank-Credentials beim nächsten Neustart bereits abgelaufen, wenn kurze Rotationsintervalle gesetzt sind.

So schützt man sich

  • Secrets niemals in URLs oder Query-Parametern übertragen - bei GET in einen HTTP-Header, bei POST/PUT in Body oder Header legen (OWASP REST Security).
  • Access Tokens, Passwörter, Datenbank-Connection-Strings und Encryption-Keys nicht im Klartext loggen; vor dem Logging entfernen, maskieren, sanitisieren, hashen oder verschlüsseln (OWASP Logging Cheat Sheet).
  • Keine Secrets im Client-/Mobile-Code oder in Versionskontrolle hartkodieren; stattdessen Secret-Management zentralisieren und standardisieren (OWASP Secrets Management).
  • Zugriff auf Secrets per Access Control / IAM nach Least-Privilege beschränken und das Secret-Management über Policies durchsetzen.
  • Secrets regelmäßig (möglichst automatisiert) rotieren, damit gestohlene Credentials nur kurz gültig sind, und bei Verdacht auf Kompromittierung sofort sicher widerrufen (revoke).
  • Secrets wo möglich mit Ablaufdatum (Expiration) versehen, damit sie automatisch ungültig werden.
  • Secret-Detection einsetzen, um eingecheckte oder offengelegte Secrets zu finden, und bei einem Fund den dokumentierten Incident-Response-Prozess (Rotation/Revocation) durchlaufen.
  • TLS überall erzwingen, damit Secrets nicht im Transit abgegriffen werden können.

Quellen

Weiterlesen
ÜbersichtOWASP API Security Top 10 AngriffJWT-Angriffe