In this blog, I will be discussing JSON Web Tokens (JWT) from a practical security perspective. The focus will be on understanding how JWT works at a fundamental level and how implementation flaws in real-world applications lead to critical vulnerabilities. Rather than staying theoretical, this blog will analyze how attackers approach JWT-based systems and identify weaknesses that can result in authentication bypass and privilege escalation.
Introduction
JWT is widely used because it lets applications use authentication without having to keep sessions on the server. The server issues a token that contains all necessary user information, and the client sends this token with each request rather than storing session data on the backend. This model works well in distributed architectures and microservices where multiple services need to trust the same authentication data.
The fact that JWT gives the client more trust creates the risk. The server is relying on a token that the user stores and sends. An attacker can manipulate the token and force the server to accept it as legitimate if validation is inadequate or misconfigured. This effectively compromises access control and authentication.
This blog focuses on getting a fundamental understanding of how JWT works and how bad implementations lead to vulnerabilities in the real world.
What is JWT
A JSON Web Token (JWT) is a compact token format used to securely transmit JSON data between a client and a server. It is mostly used in authentication systems, where the server makes a token with information about the user's identity and authorization after a successful login.
The client stores this token and includes it in subsequent requests, typically in the Authorization header. Because the token already contains all of the necessary information, the server does not have to query a database or keep track of the session's state.
The important point is that JWT is not a storage mechanism for secrets. It is a transport mechanism for claims. The security of JWT depends entirely on whether the server can trust that the token has not been altered.
JSON Web Token Structure
A JWT consists of three parts separated by dots. The structure is:
HEADER.PAYLOAD.SIGNATUREEach part is Base64URL encoded, which means it is easily reversible and readable.
Header
The JWT's first section, the Header, specifies the token's metadata. It tells you what kind of token it is and how the token is signed.
Example:
{
"alg": "HS256",
"typ": "JWT"
}The signing algorithm (HMAC-SHA256) is specified by alg and the typ indicates that this is a JWT.
Base64URL encodes this JSON object, producing a string like:
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9Payload
The Payload is the second part and contains the actual data or claims about the user.
Example:
{
"sub": "1234567890",
"name": "John Doe",
"iat": 1516239022
}subrepresents the user identifiernamerepresents the usernameiatrepresents the issued-at timestamp
This payload is also Base64URL encoded, producing something like:
eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQThis forms the second part of the JWT. This data is not encrypted; rather, it is encoded, allowing anyone to decode and modify it.
Signature
The Signature is the third and most critical part of the JWT. It's used to make sure the token hasn't changed.
If the signatures match, the server assumes the token is valid and trusts the payload. If they do not match, the token should be rejected.
Example:
HMAC-SHA256(
base64Url(header) + "." + base64Url(payload),
secret
)The purpose of the signature is to ensure that the token has not been altered. When the server receives a JWT, it recalculates the signature and compares it with the one provided in the token.
If the signatures match, the server assumes the token is valid and trusts the payload. If they do not match, the token should be rejected.
This indicates that a dot is added to the encoded header and payload. The result is signed using a secret key and the HS256 algorithm.
This indicates that a dot is added to the encoded header and payload. The result is signed using a secret key and the HS256 algorithm.
Example output:
XM-XSs2Lmp76IcTQ7tVdFcZzN4W_WcoKMNANp925Q9gHow JWT Vulnerabilities Arise
JWT vulnerabilities are not caused by the format itself but by incorrect implementation decisions made during development.
Incorrect signature verification, in which the server either fails to validate the signature or does so incorrectly, is a major problem. In such cases, the server may accept tokens that have been modified by an attacker.
The use of weak or predictable signing keys is another common problem. If the secret key is simple or exposed, an attacker can generate valid signatures and create arbitrary tokens.
Misconfigured libraries also pose a risk. If strict validation is not enforced, some libraries allow multiple algorithms or fallback behaviors that can be abused.
Trusting the payload without conducting proper verification is a fundamental error. Since the payload is controlled by the client, any assumption that its contents are inherently trustworthy leads to privilege escalation and authorization bypass.
Real World JWT Attacks
For this section, I'll be using PortSwigger labs to walk through the different attack scenarios. These labs are designed to simulate real-world vulnerabilities, which makes them useful for understanding how JWT issues actually appear in applications. Instead of just explaining the concepts, this approach helps in seeing how these misconfigurations can be identified and exploited in a practical environment.
Scenario 1: JWT Authentication Bypass via Unverified Signature
To begin with the practical side of JWT attacks, I started with PortSwigger's lab on JWT authentication bypass via unverified signature. This lab demonstrates a common implementation flaw where the server accepts JWTs without validating their signature, allowing modified tokens to be trusted. The objective of the lab is to abuse this weakness, gain access to the admin panel.
Click on Access The Lab to start the lab.
Now navigate to My Account.
Login using wiener:peter credentials
We successfully logged in, now let's refresh the page and intercept it using Burpsuite Interceptor.
If you observe carefully, every request contains a session token that is sent to the server and the token appears to be in JWT format.
There are many tools to decode JWT tokens such as jwt.io, cyberchef etc.
Navigate to jwt.io and paste the JWT token that is captured in the request.
On careful observation, the sub claim specifies the user wiener. If we change the value of sub to a highly privileged user, we may be able to gain access to the admin panel.
Let's first try to access the admin panel through the browser to observe the application's initial behavior.
Now Observe this response, the admin panel only accessible for the administrator. Let's intercept the request and change the value ofsub to administrator.
To manipulate the JWT token, I am using JSON Web Token Extension in Burpsuite.
At first Intercept the request of /admin
Click on JSON Web Token tab to view the decoded JSON.
Now change the value of sub to administrator and forward the request
After sending the request, we can see that we got the access of the admin panel.
To complete the lab we need to delete the carlos user. click on delete option for carlos user and intercept the request.
Navigate to JSON Web Token tab then change the value of sub to administrator and send the request.
Do the same for the next request and visit the page in the browser.
See that the carlos user is deleted and the lab is successfully solved.
Impact
This vulnerability leads to a complete breakdown of the authentication mechanism because the application trusts JWT claims without validating the signature. Any user, including administrative accounts, can be impersonated by an attacker by altering user identity fields like sub. In real-world applications, this can result in unauthorized access to restricted panels, privilege escalation, account takeover, and execution of sensitive administrative actions such as deleting users or modifying critical data.
Remediation
The application must always verify the JWT signature before processing any claim present in the token. Signature validation should be enforced server-side using trusted keys, and unsigned or tampered tokens must be rejected immediately. The server should never rely solely on client-controlled claims such as sub or role for authorization decisions without proper verification. It is also recommended to use well-maintained JWT libraries with secure defaults and strict validation settings.
Scenario 2: JWT authentication bypass via flawed signature verification
To continue exploring JWT implementation flaws, I moved on to PortSwigger's lab on JWT authentication bypass via flawed signature verification. This lab demonstrates a scenario where the server is insecurely configured to accept unsigned JWTs, allowing an attacker to tamper with token claims and bypass authentication controls.
Click on Access The Lab to start the challenge. Once the lab is loaded, navigate to the My Account page
Login using wiener:peter credentials
We successfully logged in, now let's refresh the page and intercept it using Burpsuite Interceptor.
If you observe carefully, every request contains a session token that is sent to the server and the token appears to be in JWT format. Now copy the session token and go to jwt.io and paste the token in the JWT Decoder.
On inspection, the header shows that the token is using the RS256 signing algorithm, while the payload contains the claim sub with the value wiener, indicating the current authenticated user.
Now go to JWT Encoder.
The next step is to modify the token header by changing the algorithm from RS256 to none. This instructs vulnerable servers to treat the token as unsigned and skip signature verification entirely. After this, modify the payload and replace the sub value from wiener to administrator.
After updating the header, modify the payload by changing the sub claim from wiener to administrator. This changes the identity represented by the token from a normal user to an administrative user.
Once the modifications are complete, copy the newly generated JWT token. This forged token will be used to impersonate the administrator account.
Now intercept the /admin page using Burpsuite
In this request Replace the original session token with the forged JWT token and forward the request to the server.
Return to the browser and visit the page. It can now be observed that access to the admin panel has been granted, confirming that the manipulated token has been accepted.
To complete the lab, the next objective is to delete the user carlos. Click the delete option for the user and intercept the request in Burp Suite.
Again, replace the original session token with the forged administrator JWT token and send the request.
Finally, return to the browser and observe that the user carlos has been deleted successfully, which completes the lab.
Now Observe carefully that the carlos user is deleted.
Impact
This vulnerability can completely compromise the authentication mechanism of the application. By changing the JWT algorithm to none, an attacker can create unsigned tokens and impersonate any user by modifying claims such as sub. In real-world environments, this can lead to unauthorized access to privileged accounts, administrative panel takeover, account impersonation, sensitive data exposure, and execution of high-impact actions without valid credentials.
Remediation
The server must never accept tokens using the none algorithm unless explicitly required for a secure internal use case. Signature verification should always be enforced server-side, and the expected signing algorithm must be hardcoded rather than trusted from the token header. Applications should use well-maintained JWT libraries that disable insecure algorithms by default, reject unsigned tokens, and validate all token claims strictly before granting access.
Scenario 3: JWT authentication bypass via weak signing key
I moved on to PortSwigger's lab on JWT authentication bypass using a weak signing key to continue my investigation of implementation flaws. This lab demonstrates a scenario where the server relies on an extremely weak secret for signing tokens, making it vulnerable to brute-force attacks. Once the secret is recovered, an attacker can forge valid JWTs, manipulate claims, and gain unauthorized access to privileged functionality such as the admin panel.
Click on Access The Lab to start the challenge. Once the lab is loaded, navigate to the My Account page
Login using wiener:peter credentials
We successfully logged in, now let's refresh the page and intercept it using Burpsuite Interceptor. The request contained a session cookie named session, which held a JWT. This confirmed that the application relies on JWT-based authentication.
I pasted the JWT token into JWT Decoder to analyze the structure. Upon inspection, the header revealed that the token was signed using the HS256 algorithm, indicating a symmetric signing mechanism. The payload contained standard claims such as the user identifier (sub: wiener) and issuer. Since HS256 relies on a shared secret, this observation suggested that if the secret key is weak, it could potentially be brute-forced, allowing full control over token integrity.
Now open a Linux terminal and save the JWT token in a text file.
Using John the Ripper along with the rockyou.txt wordlist, I initiated a brute-force attack against the JWT secret. Due to the weak nature of the signing key, the process completed quickly, revealing the secret as secret1. This confirms that the application is using a highly predictable and insecure key for signing tokens.
The Secret key is secret1.
I returned to the JWT tool and switched to the encoder functionality. I modified the token claims to escalate privileges and re-signed the token using the recovered secret secret1.
Copy the forged JWT token and open the target web application. Now intercept the /admin page on the application.
Change the actual JWT token into the forged JWT token and forward the request.
Now let's visit the web page and observe that we can access the admin panel.
To complete the lab, the next objective is to delete the user carlos. Click the delete option for the user and intercept the request in Burp Suite.
Again, replace the original session token with the forged administrator JWT token and send the request.
Finally, return to the browser and observe that the user carlos has been deleted successfully, which completes the lab.
Impact
This vulnerability allows attackers to recover the JWT signing secret through offline brute-force attacks when weak or predictable keys are used. Once the secret key is exposed, the integrity of every token issued by the application is compromised. An attacker can generate valid JWTs for any user, modify claims such as identity or role, impersonate privileged accounts, access restricted administrative functionality, and perform unauthorized actions. In real-world environments, this can lead to full authentication bypass, account takeover, privilege escalation, and large-scale compromise of user sessions.
Remediation
JWT signing keys must be long, random, and cryptographically strong so they cannot be guessed or cracked using wordlists or brute-force techniques. Common words, short phrases, and predictable patterns should never be used as secrets. Secrets should be securely generated, stored in protected secret-management systems, and rotated periodically. Organizations should also monitor for outdated weak keys, invalidate previously issued tokens after key rotation, and enforce least-privilege access controls so that even if a token is abused, the impact is reduced.
Summary
These three labs demonstrate how small mistakes in JWT implementation can completely break an application's authentication model. The server begins to trust tokens controlled by an attacker as legitimate, regardless of whether the issue is a lack of signature validation, acceptance of the none algorithm, or the use of a weak signing key.
From an attacker's perspective, JWT vulnerabilities are highly valuable because they target the core trust mechanism used for identity and access control. Once that trust is broken, it becomes possible to impersonate users, escalate privileges, and gain unauthorized access to sensitive functionality such as administrative panels.
Connect With Me
If you found this writeup useful and would like to follow more content on web security, JWT attacks, and real-world exploitation techniques, feel free to connect with me.
LinkedIn: [https://www.linkedin.com/in/ayan-paul007] Medium: [https://medium.com/@AyanPaul007]