JavaScript Web Tokens, more commonly referred to as JSON Web Tokens or JWTs, are widely used in modern web applications, APIs, mobile backends, SaaS platforms, identity systems, OAuth flows, and cloud-connected services.
JWTs are useful because they can carry identity claims, authorization context, session state, expiration details, issuer information, audience restrictions, and application-specific permissions in a compact format. But JWTs are not automatically secure.
A poorly implemented JWT flow can expose applications to token forgery, privilege escalation, account takeover, API authorization bypass, replay attacks, long-lived session abuse, weak signing, unsafe storage, broken logout behavior, and excessive access across services.
Redbot Security validates JWT and token-related risk through web application and API penetration testing, API security testing and compliance validation, application security testing, cloud security testing, and red team operations.
What Are JavaScript Web Tokens?
JavaScript Web Tokens is a common mistaken phrase for JSON Web Tokens. A JWT is a compact token format used to represent claims between systems. It is often used for authentication, authorization, API access, session state, and identity federation.
A JWT commonly contains three parts: a header, a payload, and a signature. The header identifies the algorithm and token type. The payload contains claims such as user ID, issuer, audience, expiration, roles, scopes, or permissions. The signature is used to verify that the token has not been tampered with.
JWTs are often used in single-page applications, mobile applications, REST APIs, GraphQL APIs, microservices, OAuth, OpenID Connect, SaaS integrations, cloud platforms, and service-to-service communication.
The token format itself does not guarantee security. Signing, validation, storage, expiration, scoping, revocation, and authorization enforcement all matter.
How JWT Authentication Works
In a typical JWT flow, a user authenticates with an application or identity provider. If authentication succeeds, the server issues a signed token. The client then sends that token with future requests, usually in an authorization header or secure cookie.
The backend verifies the token signature, checks expiration, validates issuer and audience, evaluates claims, and then decides whether the request should be allowed.
| JWT Component | Purpose | Security Concern |
|---|---|---|
| Header | Identifies token type and signing algorithm | Weak or unsafe algorithm handling can enable token abuse |
| Payload | Contains user, role, scope, issuer, audience, and expiration claims | Sensitive data should not be placed in readable token claims |
| Signature | Validates token integrity | Weak secrets, missing validation, or algorithm confusion can break trust |
| Expiration | Limits token lifetime | Long-lived tokens increase replay and account compromise impact |
| Claims | Communicate identity and authorization context | Claims must be validated server-side and not blindly trusted |
Secure JWT usage depends on validating the token correctly on every request and enforcing authorization in the backend application, not only trusting what the client sends.
Common JWT Security Risks
JWT vulnerabilities usually appear when applications trust tokens too much, validate them too loosely, store them unsafely, or fail to enforce authorization after token validation.
These risks are especially serious in applications that expose APIs, support multi-tenant SaaS access, rely on OAuth or SSO, or connect to cloud and AI workflows.
JWT Signing and Validation Mistakes
JWT security depends heavily on correct signing and validation. If the application fails to verify the signature, uses weak secrets, accepts unsafe algorithms, or validates claims incorrectly, attackers may be able to forge or manipulate tokens.
| JWT Mistake | Potential Impact |
|---|---|
| Weak Signing Secret | Attackers may brute-force the secret and forge valid tokens |
| Missing Signature Validation | Modified tokens may be accepted by the application |
| Algorithm Confusion | The application may accept tokens signed using an unintended algorithm |
| Ignoring Expiration | Expired tokens remain usable after they should be invalid |
| Missing Audience Validation | Tokens intended for one service may be accepted by another |
| Missing Issuer Validation | Tokens from an untrusted issuer may be accepted |
Every service that accepts JWTs should verify signature, expiration, issuer, audience, algorithm, token type, and authorization context before trusting the request.
JWT Storage Risk in Browsers and Clients
JWT storage decisions have major security consequences. If tokens are stored in locations accessible to malicious JavaScript, a cross-site scripting vulnerability may become an account takeover path.
Some applications store access tokens in browser localStorage or sessionStorage. Others use secure, HttpOnly cookies. Each approach has tradeoffs, but tokens should be protected from theft, replay, and unintended exposure.
| Storage Location | Security Concern |
|---|---|
| localStorage | Accessible to JavaScript, increasing token theft risk if XSS exists |
| sessionStorage | Still JavaScript-accessible, but scoped to the browser tab session |
| HttpOnly Cookies | Protected from JavaScript access but require CSRF and SameSite controls |
| Mobile Storage | Requires secure platform storage and protection from local device compromise |
| Logs and Analytics | Tokens may leak through request logs, headers, crash reports, or monitoring tools |
Token storage should be evaluated alongside XSS defenses, CSRF protections, cookie settings, session design, refresh-token rotation, logout behavior, and monitoring.
JWT Authorization and API Security
JWT validation is not the same as authorization. A valid token proves that a token was issued by a trusted source. It does not automatically prove that the user is allowed to access every object, function, tenant, or workflow.
APIs must enforce authorization server-side after token validation. Otherwise, applications may be exposed to BOLA, IDOR, broken function authorization, tenant isolation failures, mass assignment, and workflow abuse.
| API Authorization Risk | JWT-Related Failure |
|---|---|
| BOLA / IDOR | Valid token is used to access another user’s object, record, file, or invoice |
| Broken Function Authorization | Token holder calls admin-only or privileged API functions |
| Tenant Isolation Failure | Token claims are trusted without enforcing tenant-aware object access |
| Mass Assignment | Authenticated user changes role, tenant, status, approval, or backend-only fields |
| Excessive Scope | Token grants access to more APIs, actions, or data than required |
Related authorization guidance includes BOLA API Security, Insecure Direct Object Reference, and Mass Assignment Vulnerabilities.
OAuth, OIDC, Cloud, and SaaS Token Risk
JWTs are commonly used in OAuth and OpenID Connect environments. These systems introduce additional risks around scopes, audiences, issuers, redirect URIs, token exchange, refresh tokens, identity claims, and third-party integrations.
Cloud and SaaS environments often rely on tokens to authorize access between applications, APIs, users, service accounts, automation tools, and third-party integrations.
Organizations should evaluate token usage across the full identity flow, including the application, API gateway, identity provider, backend services, cloud roles, SaaS integrations, and logging systems.
Redbot’s cloud security testing helps validate cloud identity, token, and service-account exposure.
JWT Risk in AI and LLM Systems
AI-enabled applications often use tokens to access APIs, retrieval systems, SaaS tools, cloud services, file repositories, databases, and agent workflows.
If an AI agent or RAG system uses over-scoped tokens, prompt injection or workflow manipulation may lead to unauthorized data access or unsafe tool execution.
| AI Token Risk | Potential Impact |
|---|---|
| Over-Scoped Tool Tokens | AI agents can call APIs or retrieve data beyond the user’s actual permissions |
| RAG Retrieval Tokens | Retrieval systems expose documents across roles, tenants, or ownership boundaries |
| Prompt Injection | Attackers manipulate AI workflows into using tokens or tools unsafely |
| Token Leakage in Logs | Prompts, tool traces, or agent logs expose sensitive access tokens |
| Service Account Abuse | AI systems use powerful backend identities instead of user-scoped access |
AI-connected applications should combine application security testing with AI / LLM security testing, RAG testing, and prompt injection testing.
How to Test JWT Security
JWT security testing validates how tokens are created, signed, stored, transmitted, validated, scoped, expired, refreshed, revoked, logged, and used for authorization decisions.
Manual testing is important because token security often depends on the application’s actual identity flows, API behavior, user roles, tenant boundaries, business workflows, and backend trust relationships.
For broader context on scanner limitations, review Manual Penetration Testing vs Automated Testing.
How Redbot Tests JWT and Token Security
Redbot Security tests JWT and token security as part of application, API, cloud, SaaS, and AI-connected workflow validation.
The goal is to determine whether attackers can forge tokens, replay tokens, abuse refresh tokens, bypass expiration, manipulate claims, escalate privileges, access unauthorized APIs, cross tenant boundaries, or chain token weaknesses into real business impact.
| Testing Area | Validation Objective |
|---|---|
| Token Integrity | Validate signing, algorithms, secrets, keys, tamper resistance, and signature enforcement |
| Claims Validation | Test issuer, audience, expiration, token type, roles, scopes, and tenant claims |
| Storage and Exposure | Review browser storage, cookies, logs, analytics, mobile storage, and leak paths |
| Authorization | Validate object access, role enforcement, tenant isolation, API scopes, and backend authorization |
| Lifecycle Controls | Test expiration, refresh rotation, logout, revocation, password resets, and deprovisioning |
| Connected Systems | Evaluate OAuth, OIDC, cloud APIs, SaaS integrations, AI agents, and RAG access paths |
Redbot delivers validated findings, exploit evidence, remediation guidance, and retesting support for organizations that need practical token security validation across modern applications and APIs.
Mature testing validates not only whether tokens are present, but whether token handling can be manipulated to access data, elevate privileges, bypass controls, or compromise workflows.
What are JavaScript Web Tokens?
JavaScript Web Tokens is a common mistaken name for JSON Web Tokens. JWTs are compact tokens used to carry identity and authorization claims between systems, commonly in web applications, APIs, OAuth, and OpenID Connect flows.
Are JWTs secure?
JWTs can be secure when implemented correctly, but they are not automatically secure. They must be signed properly, validated strictly, stored safely, scoped correctly, expired properly, and enforced with backend authorization checks.
What are common JWT vulnerabilities?
Common JWT vulnerabilities include weak signing secrets, missing signature validation, unsafe algorithm handling, long-lived tokens, sensitive claims in tokens, unsafe browser storage, missing issuer or audience checks, and broken authorization.
Where should JWTs be stored?
JWT storage depends on the application design, but tokens should be protected from theft and replay. Browser localStorage is exposed to JavaScript, while HttpOnly cookies reduce JavaScript access but require strong CSRF and SameSite controls.
Does a valid JWT prove authorization?
No. A valid JWT only proves that the token passed validation. The backend must still enforce authorization for objects, actions, roles, tenants, scopes, and workflows.
How do JWTs affect API security?
JWTs often control API access. Weak validation, excessive scopes, broken tenant checks, or blind trust in token claims can lead to BOLA, IDOR, privilege escalation, and unauthorized API actions.
How does Redbot Security test JWT security?
Redbot Security tests JWT security by validating signing, algorithms, claims, expiration, storage, refresh behavior, revocation, OAuth flows, API authorization, tenant isolation, cloud integrations, and AI-connected token use.
References
Application & API Testing
Web application, API, authentication, and authorization validation.
Cloud Testing
Cloud IAM, service-account, OAuth, and API trust validation.
AI / LLM Security
AI agent, RAG, prompt injection, and token-connected workflow testing.
Network Testing
Internal and external infrastructure attack-path validation.
Red Team Operations
Advanced adversarial simulation across enterprise environments.
Application Security Testing
Learn how modern application security validates APIs, identity, workflows, and cloud integrations.
API Security Testing
Understand API authorization, compliance, token, and workflow risk.
BOLA API Security
See how valid tokens can still be abused when object authorization fails.
Redbot Social