Skip to content
NeuralSkills
Sicherheit

JWT-Sicherheits-Auditor

JWT-Implementierung auf gaengige Schwachstellen auditieren — Algorithmus-Verwirrung, schwache Secrets, fehlende Ablaufzeit und Token-Leakage.

Fortgeschritten Kostenlos Veroeffentlicht: 15. April 2026
Kompatible Tools claude-codechatgptgeminicopilotcursorwindsurfuniversal

Das Problem

JSON Web Tokens sind truegerisch einfach — Payload kodieren, signieren, fertig. Doch Implementierungsfehler verwandeln JWTs in Angriffsvektoren. Der “alg: none”-Angriff umgeht die Signaturpruefung vollstaendig. Schwache HMAC-Secrets lassen sich in Minuten per Brute-Force knacken. Tokens ohne Ablaufdatum gewaehren dauerhaften Zugriff. Und die Speicherung von JWTs in localStorage setzt sie jeder XSS-Schwachstelle der Anwendung aus.

Der Prompt

Du bist ein JWT-Sicherheitsspezialist. Pruefe meine JWT-Implementierung auf bekannte Schwachstellen und Anti-Patterns.

JWT-BIBLIOTHEK: [z.B. jsonwebtoken, jose, PyJWT, java-jwt]
SIGNATURALGORITHMUS: [z.B. HS256, RS256, ES256]
TOKEN-SPEICHERUNG: [z.B. localStorage, httpOnly Cookie, Memory]

CODE:
[JWT-Erstellung, Verifizierung, Refresh-Logik und Middleware einfuegen]

Diese JWT-Sicherheitsaspekte auditieren:

1. **Algorithmus**: Wird "alg: none" explizit abgelehnt? Ist der Algorithmus bei der Verifizierung fixiert?
2. **Secret-Staerke**: Ist das HMAC-Secret mindestens 256 Bit? Hardcoded oder aus der Umgebung?
3. **Claims-Validierung**: Werden exp, iss, aud, nbf Claims gesetzt und validiert?
4. **Token-Lebensdauer**: Access-Token < 15 Min? Refresh-Token mit Rotation?
5. **Speichersicherheit**: HttpOnly + Secure + SameSite Cookies? Oder verwundbarer localStorage?
6. **Widerruf**: Koennen Tokens vor Ablauf invalidiert werden? Blocklist-Mechanismus?
7. **Payload-Sensitivitaet**: Befinden sich Secrets, Passwoerter oder personenbezogene Daten im Payload?
8. **Schluesselverwaltung**: RSA/EC-Key-Rotationsstrategie? Key-ID (kid) Header-Validierung?

Fuer jeden Befund die genaue Schwachstelle, das Angriffsszenario und die sichere Implementierung bereitstellen.

Beispielausgabe

## JWT-Audit: 4 Befunde

### KRITISCH: Algorithmus-Verwirrung moeglich
Zeile 15: jwt.verify(token, secret) — kein Algorithmus angegeben.
Angriff: Angreifer erstellt Token mit "alg: none", Signatur wird komplett uebersprungen.
Loesung: jwt.verify(token, secret, { algorithms: ['HS256'] })

### HOCH: Secret hat nur 8 Zeichen
Zeile 3: JWT_SECRET="mysecret" — in Sekunden per Brute-Force knackbar.
Loesung: 256-Bit-Secret generieren: `openssl rand -hex 32`

Wann verwenden

Dieses Audit bei jeder JWT-Authentifizierungs-Implementierung, Aenderung von Signaturalgorithmen oder Aktualisierung der Token-Refresh-Strategie ausfuehren. Unverzichtbar nach Sicherheitsvorfaellen mit Token-Diebstahl oder bei der Migration von Session- zu Token-basierter Auth. Nutzen, um die sichere Konfiguration von Drittanbieter-Auth-Bibliotheken zu verifizieren.

Profi-Tipps

  • Algorithmus immer fixieren — niemals den Token-Header bestimmen lassen, welcher Algorithmus zur Verifizierung verwendet wird. Das verhindert “alg: none”- und RS256-zu-HS256-Angriffe.
  • RS256 gegenueber HS256 bevorzugen — asymmetrische Schluessel erlauben Token-Verifizierung ohne Weitergabe des Signatur-Secrets, entscheidend fuer Microservices.
  • Refresh-Token-Rotation implementieren — bei jeder Verwendung neuen Refresh-Token ausstellen und alten invalidieren, um Token-Diebstahl zu erkennen.
  • Kurzlebige Access-Tokens verwenden — maximal 15 Minuten. Die Unannehmlichkeit haeufiger Refreshs kostet weit weniger als ein kompromittierter langlebiger Token.