Forge the Tier: Escalating Entitlements With an Unverified JWT Claim
The challenge
This AI platform picks which model you may call from the tier claim inside your JWT. You are on the free tier, but the backend trusts that claim without ever verifying the token's signature. In the workbench, edit the payload so tier becomes enterprise. The token rebuilds live as you type. Copy the whole forged token and submit it.
What you'll learn
- Understand that tier and plan claims gate features only if the token is verified
- Tamper a payload claim and watch the token re-encode in real time
- Forge an entitlement-escalated token by setting tier to enterprise
- Recognise client-trusted claims as a billing and authorization flaw
- Know that entitlements should be checked server-side, not read from a client token
Skills tested
Prerequisites
- A JWT is three base64url parts: header, payload, signature
- Entitlement claims like tier and plan live in the payload
- Basic JSON editing
How it works
Many products map a billing tier to features: read the tier claim from the user's token and decide which model, rate limit, or capability to grant. That is safe only when the token's signature has been verified, because the signature is the one thing that proves the claim was issued by the server and not edited by the holder. This backend skips verification, so the proof is missing.
With no signature check, the JWT is just a base64url-encoded list of claims you can rewrite at will. The feature gate keys on tier, so you change "tier":"free" to "tier":"enterprise". The workbench re-encodes the payload and rebuilds the token; the original signature is carried along unchanged and is now mathematically wrong, but since the server never checks it, the forged token is accepted and the enterprise model unlocks.
The deeper issue is trusting a client-held value for an authorization or billing decision. Even a perfectly signed token can drift from the real account state, which is why sensitive entitlements are best confirmed against server-side records.
Common mistakes
- Only decoding the token. Reading
tierproves nothing - the bug is that you can change it and still be trusted. - Editing the wrong field. The gate reads
tier; set it toenterprise, notmodeloruser. - Trying to fix the signature. You do not need a valid signature here; the server never verifies it.
- Submitting the decoded JSON. Submit the rebuilt token (or its payload segment), not the human-readable claims.
How to defend against it
Verify the signature before reading any claim, and treat entitlement as server-side state rather than a client-supplied value.
- Verify the JWT signature with the expected algorithm and key on every request; reject
alg:none. - Confirm tier and plan against an authoritative server-side record (the billing system), not just the token claim.
- Keep tokens short-lived so a stale or forged entitlement cannot persist.
- Log and alert on tokens whose claimed tier does not match the account, which surfaces tampering attempts.