Working with JWTs in Burp Suite

Everything in this cluster is faster from a proxy, where you can decode a token, edit a claim, re-sign, and replay in one place without hand-encoding base64url. This page shows the workflow in Burp Suite and where it hooks into each attack. The specifics of a particular extension version change over time, so this focuses on the durable workflow rather than exact menu labels. Practice on a free live target.

Why the proxy is the right place

A JWT rides in a request, usually a cookie or an Authorization: Bearer header. Burp already sits in the middle of that request in Repeater, so the token is right there to manipulate and resend against the live endpoint. The only awkward part by hand is that the parts are base64url-encoded and the signature has to be recomputed, which is exactly what a JWT editor automates. The result is a tight loop: decode, tamper, re-sign, send, read the response, repeat.

Step 1: capture and decode

Send the request carrying the token to Repeater. With a JWT extension installed you get a dedicated view that shows the header and payload decoded into readable JSON and editable in place, instead of an opaque base64url blob. Without the extension you can still copy the token out, decode the parts, and work manually, but the editor removes that friction.

Read the decoded token first, the same thirty-second triage as always: what is the alg, is there a kid/jwk/jku, and which claim decides your privileges?

Step 2: edit a claim and re-sign

Change the claim you care about, for example the role from user to admin, or the sub to another user. Then handle the signature, which depends on the attack:

• You hold the key (a cracked HS256 secret, or your own key for a jwk/jku attack): provide it to the editor and it re-signs the edited token in place. For the command line, jwt_tool tamper mode does the same:

python3 jwt_tool.py <TOKEN> -S hs256 -p 'cracked-secret' -T

• The attack removes verification (alg:none): there is nothing to sign, you set the algorithm to a none variant and blank the signature.

Step 3: automate the standard attacks

The value of the tooling is one-click versions of the attacks you now know. Whether through the Burp extension or jwt_tool alongside it, the common exploit modes are:

python3 jwt_tool.py <TOKEN> -X a      # alg:none, strip the signature
python3 jwt_tool.py <TOKEN> -X k -pk public.pem   # algorithm confusion (RS256 to HS256)
python3 jwt_tool.py <TOKEN> -X i      # inject your own jwk into the header
python3 jwt_tool.py <TOKEN> -X s -ju https://attacker.example/jwks.json   # spoof a jku JWKS

Each maps to a spoke: -X a to flawed signature verification, -X k to algorithm confusion, and -X i/-X s to header injection. Running them from or beside Burp means you can immediately replay the output into the captured request.

Step 4: replay and read the result

Send the modified request in Repeater and read the response. The confirmation is always behavioural: an admin-only page that now loads, a field in the response you could not see before, or a different authorization decision. If it is rejected, switch attacks, the editor makes it cheap to try none, then a cracked secret, then confusion, then header injection in quick succession.

Keep it to authorized targets

Editing and replaying tokens is tampering with authentication, so only do it where you are permitted. WebVerse labs are built for exactly this, so you can run the full decode-tamper-sign-replay loop against a real token without touching a system you do not own.

Where to go next

You now have the workflow and the attacks. Lock in the defensive side with preventing JWT attacks, or keep every payload within reach in the JWT cheat sheet. Or run the loop for real on a free target.