JWTs Sind Nicht Verschlüsselt: Der #1 Irrglaube, Der Zu Datenlecks Führt

Wenn Entwickler zum ersten Mal auf JSON Web Tokens (JWTs) stoßen, machen sie oft eine gefährliche Annahme: Das Token sieht aus wie verschlüsselter Kauderwelsch, also müssen die darin enthaltenen Daten sicher sein. Dieser Irrglaube hat zu unzähligen Datenlecks, der Offenlegung persönlich identifizierbarer Informationen (PII) und erheblichen Sicherheitslücken in Anwendungen weltweit geführt. Die unangenehme Wahrheit ist, dass Standard-JWTs ungefähr so sicher sind wie das Schreiben sensibler Informationen auf eine Postkarte und deren Versand per Post – jeder, der sie abfängt, kann jedes Wort lesen.

Das Grundlegende Missverständnis

JSON Web Tokens sind zum De-facto-Standard für Authentifizierung in modernen Webanwendungen geworden. Sie sind kompakt, eigenständig und können Informationen über Nutzer und Berechtigungen transportieren. Doch genau die Eigenschaften, die JWTs praktisch machen, führen auch zu häufigen Missverständnissen. Das kritische Missverständnis rührt daher, wie JWTs für Entwickler erscheinen: eine lange Zeichenkette, scheinbar zufällig, getrennt durch Punkte. Dieses Erscheinungsbild erzeugt ein falsches Sicherheitsgefühl, das Entwickler dazu verleitet, sensible Daten direkt im Token-Payload zu speichern.

Die Realität ist deutlich unsicherer, als die meisten Entwickler vermuten. Ein Standard-JWT besteht aus drei Teilen, getrennt durch Punkte: dem Header, dem Payload und der Signatur. Während die Signatur die Integritätsprüfung durch kryptografisches Signieren gewährleistet, sind der Header und der Payload lediglich Base64URL-codiert – nicht verschlüsselt. Base64-Codierung ist eine reversibel transformierende Methode, um Binärdaten in ASCII-Strings darzustellen, keine Sicherheitsmaßnahme. Jeder mit Grundkenntnissen in Programmierung kann ein JWT in Sekunden decodieren.

Verständnis von Base64-Codierung vs. Verschlüsselung

Um zu verstehen, warum das wichtig ist, müssen wir zwischen Codierung und Verschlüsselung unterscheiden. Base64-Codierung ist eine einfache, reversibel transformierende Methode, die Daten in einen bestimmten Zeichensatz umwandelt. Sie ist für Datenübertragung und -speicherung konzipiert, nicht für Sicherheit. Jede Programmiersprache bietet eingebaute Funktionen, um Base64 mit nur einer Zeile Code zu kodieren und zu dekodieren. Es sind kein Passwort, Schlüssel oder Geheimnis erforderlich, um den Vorgang umzukehren.

Verschlüsselung hingegen ist ein kryptografischer Prozess, der Daten mit einem geheimen Schlüssel transformiert, sodass sie ohne diesen Schlüssel unlesbar sind. Echte Verschlüsselung bietet Vertraulichkeit – selbst wenn jemand verschlüsselte Daten abfängt, kann er sie ohne den Entschlüsselungsschlüssel nicht lesen. Standard-JWTs, die mit Algorithmen wie HS256 oder RS256 signiert sind, sind nicht verschlüsselt. Sie sind signiert, was grundsätzlich etwas anderes bedeutet.

Die Signatur in einem JWT hat nur eine Aufgabe: zu verifizieren, dass das Token nicht manipuliert wurde und von einer vertrauenswürdigen Quelle stammt. Wenn ein Server ein JWT erstellt, generiert er eine Signatur, indem er den kodierten Header und Payload zusammen mit einem Geheimschlüssel hash-t. Wenn der Server das Token zurückerhält, berechnet er diese Signatur neu, um die Echtheit zu prüfen. Diese Signatur verbirgt jedoch nicht den Inhalt des Payloads. Jeder kann den Payload lesen; nur die Änderung des Inhalts würde die Signatur ungültig machen.

Wie Einfach Ist Es, Ein JWT Zu Decodieren?

Erstaunlich einfach. Wir demonstrieren das mit einem typischen JWT, das man in einer Webanwendung finden könnte:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VySWQiOiIxMjM0NTY3ODkwIiwiZW1haWwiOiJqb2huLmRvZUBleGFtcGxlLmNvbSIsInNzbiI6IjEyMy00NS02Nzg5Iiwic2FsYXJ5Ijo4NTAwMCwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

Um dieses Token zu decodieren, braucht man keine speziellen Tools oder Hackerfähigkeiten. Man kann jwt.io besuchen, eine beliebte JWT-Debugging-Website, das Token einfügen und sofort dessen Inhalt sehen. Alternativ kann man ein einfaches Skript in jeder Programmiersprache schreiben. In JavaScript ist es buchstäblich eine Zeile:

JSON.parse(atob(token.split('.')[1]))

In Python ist es ebenso einfach:

import base64, json
json.loads(base64.b64decode(token.split('.')[1] + '=='))

Der decodierte Payload unseres Beispiel-Tokens würde folgendes offenbaren:

{
  "userId": "1234567890",
  "email": "john.doe@example.com",
  "ssn": "123-45-6789",
  "salary": 85000,
  "iat": 1516239022
}

Dieses Beispiel zeigt eine katastrophale Sicherheitslücke. Das Token enthält eine Sozialversicherungsnummer, Gehaltsinformationen und andere persönlich identifizierbare Daten, die niemals in einem lesbaren Format übertragen werden sollten. Doch dieses Szenario tritt in Produktionssystemen häufiger auf, als die Sicherheitsgemeinschaft es gerne zugibt.

Auswirkungen in der Praxis: Datenlecks durch Missbrauch von JWT

Die Folgen, JWTs als verschlüsselte Container zu behandeln, sind nicht theoretisch. Sicherheitsforscher und Penetrationstester entdecken regelmäßig Anwendungen, die sensible Daten durch JWT-Payloads offenlegen. Häufige Beispiele sind:

Gesundheitsanwendungen speichern Patientendaten, Diagnosecodes oder Versicherungsinformationen in JWTs. Ein böswilliger Akteur, der diese Tokens abfängt, könnte geschützte Gesundheitsinformationen ohne Datenbankangriff zugreifen.

Finanzdienstleister enthalten Kontostände, Transaktionshistorien oder interne Nutzer-IDs, die auf Kontonummern verweisen. Diese Tokens, die durch Netzwerk-Intercepts oder clientseitigen JavaScript-Zugriff erlangt werden, offenbaren Finanzdaten direkt.

E-Commerce-Seiten integrieren Kreditkartennummern, Versandadressen oder Kaufhistorien in Tokens. Während Entwickler denken, Teil-Karteninformationen seien sicher, tragen sie in Kombination mit anderen geleakten Daten zur Identitätsdiebstahl bei.

Interne Unternehmensanwendungen speichern Mitarbeiter-IDs, Gehaltsstufen, Leistungsbewertungen oder Organisationshierarchien in JWTs. Werden diese Tokens durch Browser-Entwicklertools oder Netzwerkprotokolle offengelegt, können vertrauliche Unternehmensinformationen sichtbar werden.

Aktuelle Schwachstellen im Jahr 2025, wie CVE-2025-2079 und CVE-2025-20188, betrafen hartkodierte JWT-Geheimnisse, die Angreifern erlaubten, gültige Tokens zu generieren. Das grundlegende Problem geht jedoch über das Geheimnis-Management hinaus. Selbst bei ordnungsgemäß gesicherten Signaturschlüsseln bleibt die lesbare Natur der JWT-Payloads ein inhärentes Risiko, wenn Entwickler sensible Daten darin speichern.

Die Anatomie eines JWT: Was Ist Wirklich Geschützt?

Ein JWT besteht aus drei Komponenten, die jeweils eine bestimmte Funktion erfüllen:

Der Header (Base64URL-codiert) gibt den Token-Typ und den verwendeten Signaturalgorithmus an. Er sieht typischerweise so aus:

{
  "alg": "HS256",
  "typ": "JWT"
}

Der Payload (Base64URL-codiert) enthält die Claims – Aussagen über eine Entität und zusätzliche Daten. Hier machen Entwickler oft kritische Fehler, indem sie sensible Informationen speichern, von denen sie glauben, dass sie geschützt sind.

Die Signatur (kryptografisch generiert) verifiziert die Integrität des Tokens. Bei HS256 wird sie durch Hashen des kodierten Headers und Payloads mit einem Geheimschlüssel mittels HMAC-SHA256 erstellt.

Nur die Signatur bietet eine Sicherheitsfunktion, und diese ist die Integrität, nicht die Vertraulichkeit. Sie beweist, dass das Token nicht verändert wurde und von jemandem mit dem Geheimschlüssel ausgestellt wurde. Sie verbirgt jedoch nicht die Inhalte des Payloads vor neugierigen Blicken.

Was Sollte Wirklich In Einem JWT Stecken?

Wenn sensible Daten niemals im JWT-Payload erscheinen sollten, was sollte dann dort hinein? Die Antwort sind nicht-sensible Identifikatoren und Metadaten, die dem Server helfen, Anfragen zu validieren und stateless Authentifizierung zu gewährleisten.

Geeignete Inhalte im JWT-Payload sind:

• Nutzer-ID oder Benutzername (nicht-sensible Identifikatoren)
• Ablaufzeit des Tokens (exp-Claim)
• Ausstellungszeit (iat-Claim)
• Herausgeber (iss-Claim)
• Subjekt (sub-Claim)
• Zielgruppe (aud-Claim)
• Nicht-sensible Nutzerrollen oder Berechtigungen
• Sitzungs-IDs

Das wichtigste Prinzip ist, dass alles im Payload Informationen sein sollten, die Sie auch in Anwendungslogs oder Server-Konsole-Ausgaben anzeigen würden. Wenn Sie diese Daten nicht in einem Logfile haben möchten, das jemand anderes lesen könnte, gehören sie nicht in einen JWT-Payload.

Für sensible Informationen speichern Sie sie serverseitig und lassen das JWT nur eine Referenz-ID enthalten. Wenn der Server das Token erhält, extrahiert er die Nutzer-ID oder Sitzungs-ID und sucht zusätzliche Daten in einer sicheren Datenbank. Dieser Ansatz bewahrt die Vorteile der stateless-Authentifizierung und schützt gleichzeitig sensible Daten.

Die Alternative: Opaque Tokens für Sitzungsmanagement

Viele Sicherheitsexperten argumentieren, dass für das Sitzungsmanagement opaque tokens bessere Sicherheitseigenschaften bieten als JWTs. Ein opaque token ist eine zufällig generierte Zeichenkette, die als Lookup-Schlüssel für serverseitige Sitzungsdaten dient. Im Gegensatz zu JWTs offenbart ein opaque token nichts über den Nutzer oder die Sitzung – es ist für jeden, der es abfängt, völlig bedeutungslos.

Bei der Implementierung von opaque tokens generiert der Server eine kryptografisch zufällige Zeichenkette, verknüpft sie mit den Sitzungsdaten in einem sicheren Speicher (wie Redis oder einer Datenbank) und gibt das Token an den Client zurück. Bei weiteren Anfragen sendet der Client das Token, und der Server sucht die zugehörigen Sitzungsdaten. Wenn das Token nicht existiert oder abgelaufen ist, wird die Anfrage abgelehnt.

Dieser Ansatz bietet mehrere Sicherheitsvorteile. Erstens werden die Inhalte des Tokens nie offengelegt, weil es keine Inhalte gibt – nur eine zufällige Kennung. Zweitens können Sitzungen sofort widerrufen werden, indem der serverseitige Eintrag entfernt wird, was bei stateless JWTs unmöglich ist. Drittens verlässt sensible Sitzungsdaten nie die Serverumgebung.

Der Nachteil ist erhöhter Speicherbedarf auf Serverseite und Datenbankabfragen bei jeder Anfrage. Für viele Anwendungen, insbesondere bei sensiblen Daten, ist dieser Kompromiss lohnenswert. Die Sicherheitsvorteile überwiegen den minimalen Performance-Overhead.

Wann Sind JWTs Geeignet?

Trotz dieser Bedenken haben JWTs legitime Anwendungsfälle, in denen sie echte Vorteile bieten. Sie sind ideal bei Szenarien, die stateless-Authentifizierung über verteilte Systeme erfordern, etwa Microservices-Architekturen, bei denen zentrale Sitzungsdaten Flaschenhälse erzeugen würden.

JWTs eignen sich gut für API-Authentifizierung, bei der das Token nur nicht-sensible Identifikatoren trägt und das API-Gateway Signaturen verifizieren kann, ohne Datenbankabfragen durchzuführen. Sie sind nützlich bei Single Sign-On (SSO)-Systemen, bei denen mehrere Anwendungen denselben Aussteller vertrauen und die Nutzer-Authentifizierung unabhängig verifizieren müssen. Außerdem sind sie geeignet für kurzlebige Zugriffstokens in OAuth 2.0-Flows, bei denen Ablaufzeiten in Minuten gemessen werden und zusätzliche Verifikation bei sensiblen Operationen notwendig ist.

Das Wichtigste ist, zu verstehen, dass JWTs Authentifizierung und Integritätsprüfung bieten, aber keine Vertraulichkeit. Bei korrekter Nutzung – mit minimalem Payload und angemessenen Sicherheitskontrollen – erfüllen sie ihren Zweck gut. Probleme entstehen, wenn Entwickler ihre Sicherheitsmerkmale missverstehen und sie als verschlüsselte Container behandeln.

JWE: Wann Braucht Man Wirklich Verschlüsselung?

Für Szenarien, die verschlüsselte Token-Payloads erfordern, enthält die JWT-Spezifikation ein weniger bekanntes Geschwister: JSON Web Encryption (JWE). JWE-Tokens sind tatsächlich verschlüsselt und bieten Vertraulichkeit für die Payload-Inhalte. Im Gegensatz zu Standard-JWTs (technisch JWS – JSON Web Signature genannt) können JWE-Tokens ohne den Verschlüsselungsschlüssel nicht decodiert werden.

Ein JWE-Token besteht aus fünf Teilen anstelle von drei, inklusive Header für Verschlüsselungsalgorithmus und Schlüsselverwaltung, einem verschlüsselten Schlüssel, Initialisierungsvektor, Chiffretext und Authentifizierungstag. Die Payload ist wirklich verschlüsselt, z.B. mit AES-GCM, was sie für jeden unlesbar macht, der den Entschlüsselungsschlüssel nicht besitzt.

Allerdings bringt JWE erhebliche Komplexität mit sich. Das Schlüsselmanagement wird kritisch – Verlust der Verschlüsselungsschlüssel bedeutet den Verlust aller mit diesen Schlüsseln verschlüsselten Tokens. Die Performance leidet durch Verschlüsselungs- und Entschlüsselungsoperationen. Fehler in kryptografischem Code können Schwachstellen schaffen, die schlimmer sind als das Speichern von Daten im Klartext.

Die meisten Anwendungen benötigen kein JWE. Der bessere Ansatz ist, sensible Daten ganz aus den Tokens herauszuhalten, stattdessen serverseitig zu speichern und nur Referenz-IDs im Token zu verwenden. JWE sollte nur in speziellen Szenarien eingesetzt werden, z.B. beim Teilen von Authentifizierung zwischen Organisationen mit unterschiedlichen Vertrauensgrenzen.

Beste Praktiken für JWT-Sicherheit

Die Implementierung einer sicheren JWT-basierten Authentifizierung erfordert die Beachtung bewährter Praktiken, die häufige Schwachstellen adressieren:

Speichern Sie niemals sensible Daten im JWT-Payload. Das ist die wichtigste Regel. Behandeln Sie jedes JWT so, als würde es von einem Angreifer gelesen – denn statistisch gesehen werden viele es.

Verwenden Sie kurze Ablaufzeiten. Halten Sie JWT-Laufzeiten in Minuten oder Stunden, nicht in Tagen oder Wochen. Kürzere Ablaufzeiten begrenzen den Schaden bei kompromittierten Tokens.

Implementieren Sie Token-Refresh-Mechanismen. Ausstellen Sie kurzlebige Zugriffstokens zusammen mit längerlebigen, sicher gespeicherten Refresh-Tokens. Das begrenzt die Exposition bei gleichzeitiger Bequemlichkeit für den Nutzer.

Validieren Sie alle JWT-Claims. Überprüfen Sie immer die Signatur, die Ablaufzeit, den Herausgeber und ob die Zielgruppe passt. Vertrauen Sie niemals einem unvalidierten JWT.

Verwenden Sie starke Signaturalgorithmen. Bevorzugen Sie RS256 (RSA-Signaturen) gegenüber HS256 (HMAC) für bessere Schlüsselseparation. Verhindern Sie Algorithmus-Manipulationen, indem Sie serverseitig erwartete Algorithmen erzwingen, niemals das JWT-Header den Algorithmus bestimmen lassen.

Sichern Sie Signaturschlüssel. Hardcodieren Sie Geheimnisse niemals im Code oder in Versionskontrollsystemen. Nutzen Sie Umgebungsvariablen, Key-Management-Services oder dedizierte Geheimnisspeicher.

Nutzen Sie stets HTTPS. Übertragen Sie JWTs nur über verschlüsselte Verbindungen. Netzwerk-Intercepts unverschlüsselter JWT-Daten setzen Tokens dem Risiko aus.

Implementieren Sie Strategien zum Token-Rückruf. Obwohl JWTs stateless sind, sollten kritische Anwendungen Blacklisting oder minimale Sitzungszustände für Widerrufsmöglichkeiten verwenden.

Teams Schulung

Vielleicht die wichtigste Sicherheitsmaßnahme ist die Schulung der Entwickler. Der Irrglaube, JWTs seien verschlüsselt, besteht weiter, weil Entwicklern die Unterscheidung zwischen Codierung, Signierung und Verschlüsselung nicht vermittelt wird. Sicherheitstraining sollte diese Lücke explizit schließen, indem gezeigt wird, wie leicht JWTs decodiert werden können und welche Implikationen das hat.

Code-Reviews sollten jede JWT-Implementierung kennzeichnen, die sensible Daten im Payload speichert. Static-Analysis-Tools können so konfiguriert werden, dass sie gängige Muster des JWT-Missbrauchs erkennen. Sicherheitstests sollten die Inhalte der JWTs auf exponierte sensible Informationen prüfen.

Organisationen sollten klare Richtlinien für den JWT-Einsatz aufstellen, die festlegen, welche Daten in Tokens gehören und welche serverseitig gespeichert werden müssen. Die Dokumentation sollte Beispiele für korrekte und inkorrekte Implementierungen enthalten, um die Sicherheitsimplikationen deutlich zu machen.

Fazit

Der Irrglaube, dass JWTs Verschlüsselung bieten, hat zu unzähligen Datenlecks geführt und setzt Systeme weiterhin Risiken aus. Zu verstehen, dass Base64 keine Verschlüsselung ist, ist grundlegend für die sichere Implementierung von Authentifizierungssystemen. Standard-JWTs bieten Integritätsprüfung durch Signaturen, aber keinen Schutz der Payload vor Lesbarkeit.

Für sichere Anwendungsentwicklung gilt: Behandeln Sie JWT-Payloads als öffentlich lesbare Daten. Speichern Sie nur nicht-sensible Identifikatoren in Tokens, lagern Sie sensible Daten serverseitig aus und erwägen Sie opaque tokens für das Sitzungsmanagement in sicherheitskritischen Anwendungen. Folgen Sie bewährten Praktiken, validieren Sie alle Token-Claims und setzen Sie angemessene Ablaufzeiten.

Die Sicherheit moderner Webanwendungen hängt davon ab, dass Entwickler die Werkzeuge, die sie verwenden, verstehen. JWTs sind mächtig und nützlich, wenn sie richtig angewendet werden, aber gefährlich bei Missverständnissen. Wenn Sie erkennen, dass JWTs nicht verschlüsselt sind, und Ihre Systeme entsprechend gestalten, können Sie ihre Vorteile nutzen und Datenlecks vermeiden, die ihnen in Sicherheitskreisen einen schlechten Ruf eingebracht haben.

Beim nächsten Mal, wenn Sie JWT-basierte Authentifizierung implementieren, denken Sie daran: Wenn Sie diese Daten nicht in einer Server-Logdatei haben möchten, gehören sie nicht in ein JWT-Payload. Der Schutz der Privatsphäre Ihrer Nutzer und die Sicherheit Ihrer Anwendung hängen davon ab, dass Sie das richtig machen.