Two JWT Mistakes That Can Compromise Your Authentication System

Understanding JWT Verification and Cross-Site Scripting (XSS)

Authentication is one of the most important parts of any web application. Many modern applications rely on JSON Web Tokens (JWTs) to identify users and authorize requests.

JWTs are simple, fast, and stateless — but like any security mechanism, they're only as secure as their implementation.

In this article, we'll look at two common security topics:

Improper JWT verification
Cross-Site Scripting (XSS)

More importantly, we'll understand why these vulnerabilities exist and how to defend against them.

A Quick Refresher on JWT

A JWT consists of three parts:

HEADER.PAYLOAD.SIGNATURE

HEADER.PAYLOAD.SIGNATURE

The Header describes the signing algorithm.

The Payload contains the claims, such as the user's ID, role, or permissions.

The Signature is generated using the header, payload, and a secret (or private key).

The signature is the most important part because it guarantees that the payload hasn't been modified.

If even one character changes inside the payload, the signature should no longer be valid.

What Happens If the Signature Is Removed?

Imagine an attacker sends this token:

HEADER.PAYLOAD

HEADER.PAYLOAD

instead of

HEADER.PAYLOAD.SIGNATURE

HEADER.PAYLOAD.SIGNATURE

A correctly implemented JWT verification library will immediately reject the request.

However, history has shown that poorly implemented or incorrectly configured JWT verification logic can introduce serious vulnerabilities. If an application skips signature verification or accepts malformed tokens due to a bug or misconfiguration, an attacker may be able to bypass authentication checks or impersonate another user.

This isn't a weakness in JWT itself — it's a weakness in how JWT verification is implemented.

The lesson is simple:

Never implement authentication by partially decoding a JWT and trusting its contents without verifying the signature.

Always rely on well-maintained libraries that correctly validate the token before accepting it.

Why Trusted JWT Libraries Matter

A mature JWT library handles far more than simply decoding the token.

It validates:

The signature
The signing algorithm
Token expiration (exp)
Not-before (nbf)
Issuer (iss)
Audience (aud)
Invalid or malformed tokens

Trying to implement all of this yourself is easy to get wrong.

Whenever possible, use a trusted and actively maintained JWT library instead of writing custom verification logic.

Cross-Site Scripting (XSS)

The second vulnerability is Cross-Site Scripting, commonly known as XSS.

Unlike JWT attacks, XSS targets the browser.

An attacker attempts to inject malicious JavaScript into a webpage viewed by other users.

For example, imagine a website that allows users to post comments.

An attacker submits:

<script>
alert("Hacked");
</script>

<script>
alert("Hacked");
</script>

If the application stores and renders that input without sanitizing or escaping it, every user who views the page will execute that script in their browser.

Now replace the harmless alert with malicious code.

The attacker could attempt to:

Read data from Local Storage
Access tokens stored in JavaScript-accessible storage
Perform actions on behalf of the user
Modify the page
Send sensitive information to a remote server

The impact depends on what data the application exposes to client-side JavaScript.

Why Is XSS So Dangerous?

JavaScript executed through an XSS vulnerability runs with the same permissions as the legitimate application.

That means it can often access anything your own frontend code can access.

If authentication tokens are stored in Local Storage, malicious JavaScript may be able to read and exfiltrate them.

If authentication is handled using cookies marked as HttpOnly, JavaScript cannot directly read those cookies. This significantly reduces the impact of token theft through XSS.

However, HttpOnly cookies are not a complete defense against XSS. Malicious scripts can still interact with the page, perform actions as the user, manipulate the DOM, or make authenticated requests from within the victim's browser.

Mitigation Techniques

Fortunately, preventing XSS is well understood.

1. Validate and Sanitize Input

Never assume client input is safe.

Validate all incoming data and sanitize anything that will later be displayed.

2. Escape Output

Before rendering user-generated content into HTML, escape special characters instead of inserting raw HTML.

Most modern frontend frameworks help with this automatically.

3. Use HttpOnly Cookies

If authentication uses cookies, mark them as:

HttpOnly
Secure
SameSite

The HttpOnly attribute prevents JavaScript from reading the cookie directly.

4. Use SameSite Cookies

The SameSite attribute reduces the risk of Cross-Site Request Forgery (CSRF) by preventing browsers from automatically sending cookies in many cross-site requests.

It's important to understand that SameSite protects against CSRF, not XSS.

These are different vulnerabilities with different mitigation strategies.

5. Use a Content Security Policy (CSP)

A properly configured Content Security Policy restricts where JavaScript can be loaded from and significantly reduces the impact of many XSS attacks.

It should be considered an additional layer of defense rather than a replacement for proper input handling.

Key Takeaways

A JWT is only trustworthy after its signature has been successfully verified.
Never trust decoded payload data without validating the signature.
Use well-maintained JWT libraries instead of custom verification logic.
XSS occurs when untrusted input is rendered as executable JavaScript.
Store authentication cookies with the HttpOnly flag to make token theft more difficult.
Use SameSite cookies to mitigate CSRF, not XSS.
Validate input, sanitize data, escape output, and use a strong Content Security Policy.

Security isn't about relying on a single defense — it's about combining multiple layers that work together.

The more you understand how attacks work, the better you'll be at building applications that can withstand them.

Contents