Jwt Testing: Anwendung, typische Fehler, Praxiswissen und saubere Workflows

JWTs werden in modernen Webanwendungen, mobilen APIs und Single-Page-Apps fast überall eingesetzt. Der häufigste Fehler im Test ist nicht das fehlende Wissen über das Format, sondern die falsche Annahme, dass ein JWT automatisch sicher sei, nur weil es signiert oder kompakt serialisiert ist. Ein JSON Web Token ist zunächst nur ein Container für Claims. Sicherheit entsteht erst durch eine korrekte Validierung auf Serverseite, eine saubere Schlüsselverwaltung, eine sinnvolle Lebensdauer und eine robuste Autorisierungslogik.

Im Burp-Workflow taucht ein JWT meist in einem Authorization-Header, in Cookies, in Request-Bodys oder seltener in URL-Parametern auf. Der Token selbst ist nur ein Prüfpunkt. Entscheidend ist, wie die Anwendung ihn verarbeitet. Genau dort entstehen reale Schwachstellen: unsaubere Signaturprüfung, falsche Akzeptanz von Algorithmen, fehlende Bindung an Session-Kontext, unzureichende Prüfung von issuer, audience oder expiration sowie eine Autorisierung, die Claims blind vertraut.

Praktisch bedeutet das: JWT-Testing ist nie nur Decoding. Es ist immer eine Kombination aus Token-Analyse, Request-Manipulation, Zustandsprüfung und Autorisierungsvalidierung. Wer nur Header und Payload liest, findet kosmetische Auffälligkeiten. Wer dagegen Request-Flows in Repeater nachbaut, Unterschiede mit Comparer vergleicht und den gesamten Authentifizierungsprozess im Kontext von API Testing betrachtet, erkennt die wirklich relevanten Fehler.

Ein JWT besteht typischerweise aus Header, Payload und Signatur. Der Header beschreibt unter anderem den Algorithmus, die Payload enthält Claims wie sub, role, iss, aud, exp oder iat, und die Signatur soll sicherstellen, dass der Inhalt nicht unbemerkt verändert wurde. Diese Struktur ist bekannt. Interessant wird es erst bei der Frage, welche Claims tatsächlich sicherheitsrelevant sind und ob der Server sie korrekt interpretiert. Ein Claim wie role=admin ist wertlos, wenn er zwar im Token steht, aber serverseitig nie gegen eine Datenquelle oder ein Berechtigungssystem geprüft wird.

Viele Anwendungen verwenden JWTs als Ersatz für klassische Sessions. Das führt oft zu Architekturfehlern. Ein stateless Token wird dann wie eine serverseitig kontrollierte Session behandelt, obwohl Widerruf, Rotation, Logout und Device-Bindung nicht sauber umgesetzt sind. In solchen Fällen überschneidet sich JWT-Testing stark mit Session Management und Login Testing. Der Token ist dann nicht nur Authentifizierungsartefakt, sondern der zentrale Angriffspunkt für Privilegieneskalation, Replay und Session-Missbrauch.

Ein sauberer Test beginnt deshalb nicht mit Payload-Manipulation, sondern mit Kontextfragen: Woher kommt der Token? Wann wird er ausgestellt? Wie lange ist er gültig? Welche Endpunkte akzeptieren ihn? Gibt es Refresh-Tokens? Wird zwischen Access- und ID-Token unterschieden? Werden Claims nur angezeigt oder wirklich für Zugriffsentscheidungen verwendet? Erst wenn diese Fragen beantwortet sind, lohnt sich gezielte Manipulation.

Ein belastbarer JWT-Test lebt von einem sauberen Workflow. Zuerst wird der relevante Authentifizierungsfluss vollständig erfasst. Das geschieht über Proxy, Proxy History und anschließend über gezielte Reproduktion in Repeater Anleitung. Ziel ist nicht nur, einen Token zu sehen, sondern den gesamten Lebenszyklus zu verstehen: Login, Token-Ausgabe, Nutzung, Erneuerung, Logout, Fehlerfälle und Rollenwechsel.

In der Praxis ist es sinnvoll, zunächst zwei oder mehr Benutzerkonten mit unterschiedlichen Rollen zu verwenden. Ein Standardbenutzer und ein privilegierter Benutzer reichen oft aus, um Unterschiede in Claims, Headern und akzeptierten Endpunkten sichtbar zu machen. Werden dieselben APIs mit verschiedenen Tokens aufgerufen, lassen sich Autorisierungsfehler deutlich schneller erkennen als durch isolierte Token-Manipulation.

Der technische Ablauf ist meist einfach, die Interpretation nicht. Ein Access-Token im Header kann etwa so aussehen:

GET /api/v1/profile HTTP/1.1
Host: target.example
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...
Accept: application/json

Dieser Request wird in Burp abgefangen, an Repeater gesendet und dort systematisch variiert. Parallel wird der Token in Decoder oder über Decoder Anleitung analysiert. Wichtig ist dabei, nicht nur Base64URL zu dekodieren, sondern Header und Payload als Eingabepunkte zu behandeln. Jeder Claim, der Einfluss auf Identität, Rolle, Mandant, Scope oder Ablaufzeit hat, ist ein potenzieller Testvektor.

Ein robuster Ablauf für JWT-Tests umfasst typischerweise folgende Schritte:

• Token-Quelle und Transportweg identifizieren: Header, Cookie, Body oder URL
• Header, Payload und Signatur getrennt analysieren und dokumentieren
• Claims mit Benutzerrollen, API-Antworten und Berechtigungen korrelieren
• Manipulationen in Repeater reproduzierbar testen und Response-Differenzen vergleichen
• Refresh-Mechanismen, Logout-Verhalten und Token-Widerruf separat prüfen

Gerade bei APIs ist die Trennung zwischen Authentifizierung und Autorisierung zentral. Ein Token kann formal gültig sein und trotzdem auf Endpunkten akzeptiert werden, für die der Benutzer keine Rechte haben dürfte. Deshalb sollte jeder JWT-Test immer mit Endpunkt-Tests kombiniert werden. Das ist besonders relevant bei REST- und GraphQL-Schnittstellen, die in API Testing oft umfangreicher untersucht werden als klassische Weboberflächen.

Ein weiterer Punkt ist die Reproduzierbarkeit. Jeder erfolgreiche oder fehlgeschlagene Test sollte mit Original-Request, manipuliertem Request, Response-Code, Response-Body und beobachtetem Effekt dokumentiert werden. Nur so lässt sich später sauber unterscheiden, ob ein Fehler in der Signaturvalidierung, in der Claim-Auswertung oder in der Autorisierungslogik liegt.

Viele Tester dekodieren ein JWT und konzentrieren sich sofort auf role oder admin. Das ist verständlich, aber oft zu kurz gedacht. Sicherheitsrelevant ist jeder Claim, der serverseitige Entscheidungen beeinflusst. Dazu gehören offensichtliche Felder wie sub, role, permissions, scope oder tenant_id, aber auch technische Claims wie iss, aud, exp, nbf, iat, jti und azp. Gerade in verteilten Systemen mit mehreren Diensten entscheidet die korrekte Prüfung dieser Felder darüber, ob ein Token nur für den vorgesehenen Zweck oder systemweit missbrauchbar ist.

Ein typisches Beispiel:

{
  "sub": "10042",
  "email": "user@example.com",
  "role": "user",
  "tenant_id": "acme",
  "scope": "profile:read invoices:read",
  "iss": "https://auth.example.com",
  "aud": "billing-api",
  "iat": 1710000000,
  "exp": 1710003600,
  "jti": "8f4d1c2a"
}

Hier sind mehrere Angriffspunkte denkbar. Wird tenant_id für Mandantentrennung verwendet, kann eine Manipulation zu Cross-Tenant-Zugriff führen. Wird aud nicht geprüft, akzeptiert möglicherweise ein anderer Dienst denselben Token. Wird jti nicht gegen eine Sperrliste oder Replay-Logik verwendet, kann ein abgefangener Token trotz Logout oder Rotation weiter funktionieren. Wird exp nur clientseitig ausgewertet oder mit zu großzügiger Clock-Skew behandelt, verlängert sich die effektive Gültigkeit.

Auch der Header verdient mehr Aufmerksamkeit, als ihm oft gegeben wird. Felder wie alg, typ, kid, jku oder x5u können sicherheitsrelevant sein. Besonders kid ist interessant, wenn der Server anhand dieses Werts den Schlüssel auswählt. Unsichere Implementierungen verwenden kid direkt in Dateipfaden, Datenbankabfragen oder Cache-Lookups. Daraus können Path Traversal, Key Confusion oder sogar Injection-nahe Effekte entstehen, wenn die Schlüsselauflösung schlecht implementiert ist.

Ein weiterer häufiger Denkfehler: Nicht jeder sichtbare Claim wird serverseitig verwendet. Manche Anwendungen schreiben role=admin in den Token, prüfen aber intern ausschließlich Datenbankrechte. Andere verlassen sich vollständig auf den Token und ignorieren serverseitige Zustände. Beides muss getestet werden. Der Unterschied zeigt sich nur durch kontrollierte Manipulation und Beobachtung des tatsächlichen Verhaltens.

Hilfreich ist der Vergleich mehrerer Tokens aus unterschiedlichen Situationen: vor und nach Passwortänderung, vor und nach Rollenänderung, bei verschiedenen Mandanten, nach Logout, nach Refresh und zwischen Web- und Mobile-Client. Mit Comparer Anwendung lassen sich diese Unterschiede schnell sichtbar machen. Dadurch wird klar, welche Claims stabil sind, welche dynamisch wechseln und welche offenbar nur kosmetischen Charakter haben.

Besondere Aufmerksamkeit verdienen folgende Claim-Kategorien:

• Identitätsclaims wie sub, uid, email oder username, wenn sie direkt für Objektzugriffe verwendet werden
• Autorisierungsclaims wie role, permissions, groups oder scope, wenn sie serverseitig nicht zusätzlich validiert werden
• Kontextclaims wie tenant_id, org_id oder region, wenn sie Mandantengrenzen oder Datenräume definieren
• Zeit- und Replay-Claims wie exp, nbf, iat und jti, wenn Widerruf, Rotation oder Ablauf nicht sauber umgesetzt sind

Ein professioneller Test bewertet Claims daher nie isoliert, sondern immer im Zusammenspiel mit Endpunkten, Rollenmodell und Backend-Architektur. Erst daraus ergibt sich, ob ein sichtbarer Wert tatsächlich sicherheitskritisch ist.

Die bekanntesten JWT-Probleme sind alt, aber keineswegs verschwunden. Vor allem in Eigenentwicklungen, Legacy-Backends und schlecht gepflegten Bibliotheken tauchen sie weiterhin auf. Der wichtigste Grundsatz lautet: Ein Token darf niemals auf Basis seines eigenen Headers entscheiden, wie er validiert wird, ohne dass der Server eine feste, vertrauenswürdige Konfiguration dagegenhält.

Der Klassiker ist alg=none. Dabei wird der Header so manipuliert, dass kein Signaturalgorithmus mehr verwendet wird. Akzeptiert der Server anschließend einen unsignierten Token, ist die Authentifizierung praktisch gebrochen. Ein Test sieht vereinfacht so aus:

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

Wird danach eine manipulierte Payload ohne gültige Signatur akzeptiert, liegt ein kritischer Fehler vor. In modernen Frameworks ist das seltener geworden, aber in proprietären Implementierungen oder falsch konfigurierten Middleware-Ketten weiterhin realistisch.

Ebenso relevant ist die Verwechslung von symmetrischen und asymmetrischen Algorithmen. Wenn ein Server eigentlich RS256 erwartet, aber den Algorithmus aus dem Token-Header übernimmt und anschließend denselben öffentlichen Schlüssel fälschlich als HMAC-Secret verwendet, kann ein Angreifer einen Token selbst signieren. Dieser Fehler ist als Algorithm Confusion bekannt. In der Praxis ist er nicht immer trivial auszunutzen, aber die Testidee ist klar: Header-Algorithmus ändern, Payload manipulieren, Signatur mit einem fehlinterpretierten Schlüsselmodell erzeugen und prüfen, ob der Server den Token akzeptiert.

Ein weiterer Bereich betrifft kid-basierte Schlüsselwahl. Wenn der Server etwa so arbeitet, dass er anhand von kid einen Schlüssel aus dem Dateisystem lädt, kann eine Manipulation des Headers gefährlich werden:

{
  "alg": "HS256",
  "kid": "../../../../dev/null",
  "typ": "JWT"
}

Ob daraus ein echter Exploit wird, hängt von der Implementierung ab. Möglich sind Dateipfadmanipulation, Fallback auf leere oder bekannte Schlüssel, Cache-Poisoning oder unerwartete Schlüsselauflösung. Solche Fehler sind selten offensichtlich und erfordern saubere Hypothesenbildung. Responses mit 500er-Fehlern, veränderten Fehlermeldungen oder abweichenden Laufzeiten sind hier oft die ersten Indikatoren.

Auch Remote-Key-Referenzen über jku oder x5u sind kritisch, wenn der Server externe Schlüsselquellen akzeptiert. Wird eine vom Token kontrollierte URL geladen, kann ein Angreifer einen eigenen Schlüssel bereitstellen und damit gültig wirkende Tokens erzeugen. In produktiven Umgebungen ist das ein schwerer Designfehler, weil die Vertrauenskette aus dem Token selbst abgeleitet wird.

Bei diesen Tests ist Vorsicht wichtig. Viele Systeme reagieren auf fehlerhafte Tokens mit generischen 401-Antworten. Das bedeutet nicht automatisch, dass die Prüfung sicher ist. Relevant sind Unterschiede: Wird ein manipuliertes Token anders behandelt als ein zufällig kaputter Token? Gibt es Timing-Differenzen? Werden bestimmte Header-Felder geloggt oder reflektiert? Solche Details entscheiden darüber, ob ein Verdacht belastbar ist.

JWT-Schwachstellen überschneiden sich häufig mit Authentication Bypass. Wer nur auf sichtbare Fehlermeldungen achtet, übersieht oft, dass die eigentliche Schwachstelle nicht im Tokenformat liegt, sondern in der Vertrauenslogik des Backends.

Die meisten kritischen JWT-Funde entstehen nicht durch exotische Kryptofehler, sondern durch fehlerhafte Autorisierung. Ein signierter Token kann technisch korrekt validiert werden und trotzdem zu unsicherem Verhalten führen, wenn das Backend Claims blind vertraut. Genau hier liegt der größte praktische Mehrwert im Test.

Ein typisches Muster ist die direkte Verwendung von sub oder user_id aus dem Token, um Datenbankabfragen zu steuern. Wenn gleichzeitig Objekt-IDs im Pfad oder Body manipulierbar sind, entsteht oft eine Kombination aus JWT-Vertrauen und Idor. Beispiel: Der Token enthält sub=10042, der Request ruft aber /api/users/10043/orders auf. Wenn der Server nur prüft, ob der Token gültig ist, aber nicht, ob die angeforderte Ressource zum Benutzer gehört, liegt ein Autorisierungsfehler vor.

Noch kritischer wird es bei Multi-Tenant-Systemen. Dort finden sich Claims wie tenant, org, account oder workspace. Wird dieser Wert aus dem Token übernommen und nicht serverseitig gegen die tatsächliche Benutzerzuordnung geprüft, kann eine Manipulation oder ein falsch ausgestellter Token zu Cross-Tenant-Zugriff führen. In SaaS-Umgebungen ist das oft ein hochkritischer Befund, weil dadurch Daten verschiedener Kunden vermischt werden.

Ein realistischer Testansatz ist, zwei Benutzer aus unterschiedlichen Rollen oder Mandanten zu verwenden und dieselben Endpunkte mit beiden Tokens aufzurufen. Danach werden Pfadparameter, Body-Felder und Header in Kombination variiert. Besonders aufschlussreich sind Fälle, in denen der Token eines Benutzers A mit Ressourcen von Benutzer B kombiniert wird. Wenn die Anwendung nur auf den Token vertraut, aber die Ressourcenzuordnung nicht prüft, wird der Zugriff akzeptiert.

Ein Beispiel für einen problematischen Request:

GET /api/v1/invoices/78421 HTTP/1.1
Host: target.example
Authorization: Bearer <token-von-user-a>
X-Tenant-ID: beta-corp

Wenn derselbe Token im ursprünglichen Kontext zu tenant_id=acme gehört, aber der Server X-Tenant-ID oder einen manipulierten Claim bevorzugt, ist die Mandantentrennung angreifbar. Solche Fehler sind häufig nicht auf einen einzelnen Parameter beschränkt. Oft existieren mehrere konkurrierende Quellen für Identität und Kontext: Token-Claim, URL, Header, Session-Objekt und Datenbankeintrag. Sobald diese Quellen nicht konsistent validiert werden, entstehen Lücken.

Besonders häufig sind folgende Fehlmuster:

• role oder scope werden aus dem Token übernommen, ohne serverseitige Rechteprüfung gegen aktuelle Daten
• sub identifiziert den Benutzer, aber Objektzugriffe werden nicht gegen Eigentum oder Berechtigung geprüft
• tenant_id oder org_id steuern Datenräume, ohne dass die Zugehörigkeit serverseitig verifiziert wird
• ID-Token oder Refresh-Token werden fälschlich als Access-Token akzeptiert
• abgelaufene oder widerrufene Tokens funktionieren auf einzelnen Endpunkten weiter

Gerade der letzte Punkt wird oft übersehen. Unterschiedliche Microservices validieren Tokens nicht immer konsistent. Ein Gateway lehnt den Token ab, ein interner Service akzeptiert ihn noch. Deshalb sollten kritische Endpunkte immer direkt und über alternative Pfade getestet werden. Wer nur die Hauptoberfläche prüft, verpasst häufig die eigentlichen Autorisierungslücken.

Viele Teams betrachten JWT-Sicherheit nur auf Ebene des Access-Tokens. In realen Anwendungen ist aber der gesamte Lebenszyklus entscheidend. Ein formal korrekt signierter Access-Token nützt wenig, wenn Refresh-Tokens unbegrenzt wiederverwendbar sind, Logout keine Wirkung hat oder ein gestohlener Token auf mehreren Geräten parallel funktioniert.

Ein klassischer Testfall ist Replay. Ein Access-Token wird abgefangen, gespeichert und nach Logout erneut verwendet. Wird der Zugriff weiterhin akzeptiert, muss geklärt werden, ob das beabsichtigt ist oder ob ein serverseitiger Widerruf fehlt. Bei rein statelessen Access-Tokens kann das Design so gewollt sein, ist aber nur dann vertretbar, wenn die Lebensdauer sehr kurz ist und das Risiko bewusst getragen wird. In vielen Anwendungen ist die Gültigkeit jedoch zu lang, sodass ein abgefangener Token praktisch eine vollwertige Session darstellt.

Noch problematischer sind Refresh-Tokens. Werden sie nicht rotiert oder nach Nutzung nicht invalidiert, kann ein einmal abgegriffener Refresh-Token dauerhaft neue Access-Tokens erzeugen. Das ist besonders kritisch bei mobilen Clients und SPAs, in denen Refresh-Tokens oft lange gültig sind. Ein sauberer Test prüft daher:

Erstens, ob ein Refresh-Token mehrfach verwendet werden kann. Zweitens, ob nach Passwortänderung oder Logout noch neue Access-Tokens ausgestellt werden. Drittens, ob parallele Nutzung erkannt wird. Viertens, ob Refresh-Tokens an Gerät, Client oder Session-Kontext gebunden sind. Fünftens, ob alte Access-Tokens nach Rotation weiterhin funktionieren.

Ein Beispielrequest für Token-Erneuerung:

POST /oauth/token HTTP/1.1
Host: target.example
Content-Type: application/json

{
  "grant_type": "refresh_token",
  "refresh_token": "r1.eyJ..."
}

Wenn derselbe Refresh-Token mehrfach neue Access-Tokens liefert, liegt mindestens ein Designproblem vor. Ob daraus ein Befund mit hoher Kritikalität wird, hängt von Schutzmaßnahmen wie Device-Bindung, kurzer Lebensdauer und Missbrauchserkennung ab. In vielen Fällen fehlt all das.

JWT-Testing überschneidet sich hier stark mit Oauth Testing, weil Access- und Refresh-Tokens oft Teil eines OAuth- oder OpenID-Connect-Flows sind. Besonders wichtig ist die Unterscheidung zwischen ID-Token und Access-Token. Wenn APIs versehentlich ID-Tokens akzeptieren, wird ein Token für Identitätsaussagen als Berechtigungsnachweis missbraucht. Das ist kein theoretischer Randfall, sondern in schlecht integrierten Systemen regelmäßig zu sehen.

Auch Logout muss präzise bewertet werden. Viele Anwendungen löschen nur clientseitig den Token, ohne serverseitig etwas zu widerrufen. Das ist bei kurzen Access-Tokens eventuell tolerierbar, bei langlebigen Tokens oder wiederverwendbaren Refresh-Tokens jedoch gefährlich. Ein professioneller Test dokumentiert deshalb immer, welche Artefakte nach Logout noch funktionieren und über welchen Zeitraum.

JWT-Tests werden deutlich effizienter, wenn Burp-Werkzeuge nicht isoliert, sondern abgestimmt eingesetzt werden. Der Kern liegt fast immer in Repeater. Dort werden Requests mit Original- und Testtokens reproduzierbar verglichen. Decoder ist nützlich für die schnelle Sicht auf Header und Payload, ersetzt aber keine echte Validierungsanalyse. Comparer hilft, Unterschiede zwischen Rollen, Zeitpunkten und Token-Varianten sichtbar zu machen. Intruder ist dann sinnvoll, wenn systematisch Claims, Header-Felder oder Endpunktkombinationen variiert werden sollen.

Ein typischer Fehler ist der Einsatz von Intruder ohne Hypothese. Wer einfach role, sub und exp mit zufälligen Werten füttert, erzeugt Rauschen. Sinnvoller ist es, gezielt auf beobachtete Logik zu testen. Wenn etwa zwei Benutzer unterschiedliche scope-Werte erhalten und ein bestimmter Endpunkt nur beim privilegierten Token funktioniert, kann Intruder verwendet werden, um Scope-Kombinationen oder Header-Varianten systematisch zu prüfen. Das spart Zeit und liefert belastbare Ergebnisse.

Für manuelle JWT-Tests hat sich folgender Werkzeugmix bewährt:

Decoder zum schnellen Zerlegen des Tokens, Repeater für kontrollierte Manipulationen, Comparer für Vorher-Nachher-Analysen und Intruder für strukturierte Variantenprüfungen. Ergänzend können Erweiterungen aus dem Bapp Store hilfreich sein, etwa für JWT-Parsing oder Signaturunterstützung. Trotzdem sollte der Kern des Tests nachvollziehbar bleiben. Wer sich vollständig auf Erweiterungen verlässt, übersieht leicht, was serverseitig tatsächlich passiert.

Ein praktisches Beispiel in Repeater ist die manuelle Variation eines Claims bei unveränderter Signatur. Wird der manipulierte Token trotzdem akzeptiert, ist das ein starkes Indiz für fehlende oder fehlerhafte Signaturprüfung. Wird er abgelehnt, folgt der nächste Schritt: Header-Felder ändern, Token-Typen tauschen, abgelaufene Tokens wiederverwenden, alternative Endpunkte testen und Unterschiede dokumentieren.

Intruder eignet sich besonders für folgende Szenarien: Variation von kid-Werten, Test unterschiedlicher Bearer-Präfixe, Prüfung mehrerer Endpunkte mit demselben Token, Austausch von Token-Typen und systematische Replay-Tests. Dabei sollte die Last kontrolliert bleiben. Authentifizierungs- und Autorisierungssysteme reagieren oft empfindlich auf hohe Fehlerraten, Sperrmechanismen oder Rate Limits.

Wer tiefer in Burp einsteigen will, profitiert zusätzlich von Intruder Anleitung, Repeater Beispiele und einer sauberen Arbeitsweise aus Workflow. JWT-Testing ist kein Spezialfall außerhalb des normalen Pentest-Prozesses, sondern ein Teil sauberer Authentifizierungs- und API-Prüfung.

JWT-Tests produzieren viele Auffälligkeiten, aber nicht jede davon ist eine Schwachstelle. Ein dekodierbarer Payload ist kein Problem, solange keine sensiblen Geheimnisse enthalten sind und die Signatur korrekt geprüft wird. Ein sichtbarer role-Claim ist ebenfalls nicht automatisch kritisch, wenn der Server Rechte zusätzlich serverseitig validiert. Umgekehrt können kleine Unterschiede in Fehlermeldungen oder Statuscodes auf tiefere Probleme hinweisen.

Ein häufiger Irrtum ist die Annahme, dass Base64URL-kodierte Daten verschlüsselt seien. Wenn ein Token E-Mail-Adressen, interne IDs oder Rollen enthält, ist das allein noch kein Sicherheitsfehler. Kritisch wird es erst, wenn vertrauliche Daten ohne Notwendigkeit im Token landen oder wenn diese Claims für Entscheidungen missbraucht werden, ohne dass ihre Integrität sauber geprüft wird.

Ebenso wichtig ist die Unterscheidung zwischen Signaturfehler und Autorisierungsfehler. Wenn ein manipuliertes Token mit 401 abgelehnt wird, ist die Signaturprüfung möglicherweise korrekt. Wenn aber ein unveränderter Token auf einem fremden Objekt 200 liefert, liegt trotzdem eine Schwachstelle vor. Viele Berichte fokussieren zu stark auf Token-Manipulation und übersehen, dass die eigentliche Lücke in der Ressourcenprüfung liegt.

Auch Response-Differenzen müssen sauber gelesen werden. Ein 401 kann bedeuten: Token ungültig. Ein 403 kann bedeuten: Token gültig, aber keine Rechte. Ein 404 kann absichtlich Autorisierung verschleiern oder tatsächlich Ressource nicht gefunden bedeuten. Ein 500 nach kid-Manipulation kann auf unsichere Schlüsselauflösung hindeuten. Ein leicht verändertes Timing bei jku-Tests kann auf externe Schlüsselabfragen hinweisen. Solche Nuancen entscheiden darüber, ob ein Test weiterverfolgt werden sollte.

Besonders wertvoll ist der Vergleich mit Kontrollfällen. Neben dem eigentlichen Testrequest sollte immer ein bewusst kaputter Token, ein abgelaufener Token, ein Token eines anderen Benutzers und möglichst ein Request ohne Token getestet werden. Erst diese Vergleichsbasis macht sichtbar, ob eine Reaktion ungewöhnlich ist oder dem normalen Fehlerverhalten entspricht.

Ein weiterer Punkt ist die Trennung zwischen Sicherheitsproblem und Architekturentscheidung. Kurze stateless Access-Tokens ohne serverseitigen Widerruf sind nicht automatisch falsch. Werden sie jedoch mit langer Laufzeit, fehlender Rotation und schwachen Refresh-Mechanismen kombiniert, entsteht ein reales Risiko. Bewertung ohne Kontext führt hier schnell zu falschen Schlüssen.

Wer JWT-Funde sauber einordnet, vermeidet zwei Extreme: harmlose Auffälligkeiten als kritisch zu melden und echte Autorisierungslücken als bloße Implementierungsdetails abzutun. Genau diese Trennschärfe macht den Unterschied zwischen oberflächlichem Testen und belastbarer Sicherheitsanalyse.

Ein guter JWT-Befund besteht nicht aus der Aussage, dass ein Token manipuliert wurde. Er besteht aus einer klaren Ursache-Wirkungs-Kette. Dazu gehört der originale Request, die exakte Manipulation, die beobachtete Serverreaktion, die sicherheitliche Auswirkung und eine nachvollziehbare Einordnung. Ohne diese Elemente bleibt der Fund angreifbar oder missverständlich.

Ein belastbarer Testfall könnte so aufgebaut sein: Benutzer A meldet sich an und erhält einen Access-Token mit role=user und tenant_id=acme. Anschließend wird ein Endpunkt aufgerufen, der Rechnungen eines anderen Mandanten liefert. Der Request wird in Repeater kopiert. Danach wird entweder ein fremdes Objekt direkt angefordert oder ein Kontextparameter wie X-Tenant-ID manipuliert. Wenn der Server Daten des fremden Mandanten zurückgibt, obwohl der Token nicht dazu berechtigt ist, liegt eine reproduzierbare Cross-Tenant-Autorisierungslücke vor.

Ebenso wichtig ist die Dokumentation negativer Tests. Wenn alg=none nicht funktioniert, kid-Manipulation aber zu einem internen Fehler führt, ist das kein Volltreffer, aber ein relevanter Hinweis auf unsaubere Implementierung. Solche Zwischenergebnisse helfen, das Risikobild korrekt zu zeichnen und spätere Nachtests effizienter zu machen.

Für die Berichtsqualität sind folgende Punkte entscheidend: exakte Endpunkte, vollständige Requests, Token-Typ, Benutzerrolle, Zeitpunkt, Response-Code, relevante Response-Ausschnitte und klare Beschreibung der Auswirkung. Bei Replay- oder Logout-Problemen sollte zusätzlich die Zeitspanne dokumentiert werden, in der ein Token weiterverwendbar bleibt. Bei Rollen- oder Mandantenfehlern muss klar erkennbar sein, welche Daten oder Funktionen unzulässig erreichbar waren.

Ein Beispiel für eine knappe, aber belastbare technische Beschreibung:

1. Login als Benutzer A und Erhalt eines gültigen Access-Tokens.
2. Aufruf von GET /api/v1/admin/users mit Token von Benutzer A.
3. Server antwortet mit HTTP 200 und liefert Administrationsdaten.
4. Vergleich mit Benutzer B zeigt, dass derselbe Endpunkt nur über den Token-Claim "scope" gesteuert wird.
5. Nach Rollenänderung in der Datenbank bleibt der alte Token bis zum Ablauf administrativ nutzbar.

Diese Darstellung zeigt nicht nur, dass etwas funktioniert hat, sondern auch warum der Fehler relevant ist. Besonders bei JWT-Themen ist das wichtig, weil viele Stakeholder den Unterschied zwischen Tokenformat, Signaturprüfung und Autorisierung nicht sauber trennen. Eine präzise Dokumentation verhindert Missverständnisse und erleichtert die Behebung.

Wer regelmäßig mit solchen Fällen arbeitet, profitiert von einem standardisierten Vorgehen aus Pentesting und Web Pentest. JWT-Testing ist dann kein isolierter Spezialtest, sondern ein fester Bestandteil professioneller Authentifizierungs- und API-Prüfung.

Ein professioneller Test endet nicht beim Nachweis der Schwachstelle. Entscheidend ist auch, welche Gegenmaßnahmen technisch sinnvoll sind. Robuste JWT-Implementierungen folgen einigen klaren Prinzipien. Der Server akzeptiert nur explizit konfigurierte Algorithmen, niemals blind den Wert aus dem Token. Schlüsselquellen sind fest definiert und nicht durch Header-Felder steuerbar. Claims wie iss, aud, exp und nbf werden konsequent geprüft. Access-, ID- und Refresh-Tokens werden strikt getrennt behandelt. Autorisierung basiert nicht allein auf Token-Claims, sondern auf serverseitig verifizierten Berechtigungen oder zumindest auf konsistent validierten Kontexten.

Auch die Lebensdauer ist entscheidend. Kurze Access-Tokens reduzieren Replay-Risiken, ersetzen aber keine saubere Refresh-Logik. Refresh-Tokens sollten rotiert, an Kontext gebunden und nach Nutzung invalidiert werden. Logout, Passwortänderung und sicherheitsrelevante Kontoereignisse müssen bestehende Token wirksam entwerten oder ihre weitere Nutzung zumindest stark begrenzen.

Besonders wichtig ist die Trennung von Identität und Berechtigung. Ein Token darf Identität transportieren, aber kritische Rechte sollten nicht dauerhaft in langlebigen Tokens eingefroren werden, wenn sich Rollen oder Mandantenzuordnungen kurzfristig ändern können. Sonst entsteht das Problem veralteter Berechtigungen: Der Benutzer wurde serverseitig herabgestuft, der alte Token funktioniert aber bis zum Ablauf weiter mit erhöhten Rechten.

In verteilten Architekturen müssen alle Services dieselben Validierungsregeln anwenden. Unterschiedliche Bibliotheken, Clock-Skews, Audience-Prüfungen oder Schlüsselstände führen schnell zu Inkonsistenzen. Genau daraus entstehen in der Praxis viele schwer erkennbare Lücken. Ein Gateway, das streng prüft, hilft wenig, wenn ein interner Service Tokens lockerer akzeptiert.

Aus Sicht des Testers sind gute Gegenmaßnahmen oft an ihrem Verhalten erkennbar: manipulierte Tokens werden konsistent abgelehnt, abgelaufene Tokens funktionieren nirgends mehr, Rollenänderungen wirken zeitnah, Refresh-Tokens sind nicht wiederverwendbar und Endpunkte prüfen Ressourcenbezug unabhängig vom Tokeninhalt. Wenn diese Eigenschaften fehlen, ist das fast immer ein Hinweis auf strukturelle Schwächen.

Wer Burp in solchen Prüfungen regelmäßig einsetzt, sollte die Grundlagen aus Anleitung und die Zusammenhänge aus Wie Funktioniert sicher beherrschen. JWT-Testing ist kein Trick mit einzelnen Payloads, sondern die systematische Prüfung von Vertrauen, Zuständen und Berechtigungen über mehrere Requests und Komponenten hinweg.