🔐 How to Prevent Expired JWT Token Reuse and API Authorization Bypass?

Vignesh Nagarajan — Wed, 12 Aug 2026 09:40:37 +0000

I’m looking for suggestions from developers, security engineers, and penetration testers who have handled similar issues in production applications.

I recently came across an interesting security scenario involving JWT token reuse, session termination, and Burp Suite response manipulation.

1️⃣ The Scenario

My application has:

⚛️ React frontend
☕ Spring Boot backend
🔑 JWT-based authentication
🌐 HTTPS
🛡️ Role and permission-based authorization

During security testing, the tester captures a valid access token and attempts to reuse it after the token has expired or the session has been terminated.

Expected behavior

User Login
    ↓
Access Token Issued
    ↓
Token Expires / Session Terminates
    ↓
Old Token Becomes Invalid
    ↓
Attacker Replays Old Token
    ↓
Backend Rejects Request

The main requirement is:

An expired, revoked, or terminated token must never be accepted for a protected API operation.

2️⃣ The Interesting Part — Burp Suite

There is another aspect that makes this scenario interesting.

Suppose the backend correctly identifies the token as invalid and returns:

HTTP/1.1 401 Unauthorized

The tester can intercept the response using Burp Suite and change it to:

HTTP/1.1 200 OK

before the response reaches the React application.

Flow

Attacker
    ↓
Expired / Invalid Token
    ↓
Spring Boot
    ↓
401 Unauthorized
    ↓
Burp Suite
    ↓
401 → 200
    ↓
React receives modified response

I understand that the browser is an untrusted environment and that an attacker controlling their browser can modify HTTP requests and responses.

However, my question is:

What is the industry-standard approach to ensure that this type of manipulation cannot result in an actual unauthorized server-side operation?

3️⃣ What I Have Already Considered

🔑 Authentication

Short-lived access tokens
JWT signature validation
JWT expiration validation
Refresh-token rotation
HttpOnly + Secure cookies

🚫 Token / Session Management

Server-side session invalidation
Token/session versioning
Token revocation
Invalidating previously issued tokens after logout

👮 Authorization

Permission validation on every protected API
Role-based authorization
Server-side authorization
Never trusting frontend role/permission information

4️⃣ Token Replay Scenario

For example, suppose an attacker captures:

Token A

Later:

Token A
   ↓
Expires / Session Terminated
   ↓
Attacker Replays Token A
   ↓
Protected API

The backend should independently validate:

JWT Signature
      ↓
Expiration
      ↓
Session Validity
      ↓
Token Status
      ↓
User Status
      ↓
Permission
      ↓
Business Authorization

Only if all validations succeed should the operation be performed.

5️⃣ Expected Security Model 🛡️

Attacker Captures Token A
          ↓
Token A Expires / Session Terminates
          ↓
Attacker Replays Token A
          ↓
Backend Independently Validates
          │
          ├── 🔑 JWT Signature
          ├── ⏳ Expiration
          ├── 🔒 Session Validity
          ├── 🚫 Token Status
          ├── 👤 User Status
          └── 👮 Authorization
                  ↓
               REJECT
                  ↓
       Protected Operation NOT Performed

6️⃣ JWT vs Session-Based Authentication

This also raises an architectural question.

Approach	Token Revocation	Replay Protection	Complexity
Long-lived JWT	Hard	Weak	Low
Short-lived JWT	Better	Better	Medium
JWT + Server-side Session	Strong	Strong	Medium
Opaque Session Token	Strong	Strong	Medium

7️⃣ Refresh Token Replay 🔄

Another area I am particularly interested in is refresh-token reuse.

Refresh Token A
      ↓
Refresh Request
      ↓
Token A Invalidated
      ↓
Refresh Token B Issued
      ↓
Attacker Reuses Token A
      ↓
Replay Detected
      ↓
Reject / Terminate Session

What is the recommended production approach for detecting and handling this type of refresh-token replay?

8️⃣ My Questions to the Community ❓

What is the recommended architecture for preventing JWT replay/token reuse after logout or session termination?
Is JWT alone appropriate when immediate token invalidation is required?
Should access tokens be short-lived with refresh-token rotation?
What is the recommended way to invalidate previously issued access tokens?
How should a backend detect and handle refresh-token replay?
Would opaque/session-based tokens be a better alternative when strong revocation is required?
From a penetration-testing perspective, what is the standard remediation when a previously issued token can still be reused?
If the backend correctly returns 401 but Burp changes it to 200 before it reaches React, is there an accepted way to prevent the frontend from trusting the manipulated response?

9️⃣ The Important Distinction

I understand that these are two different scenarios:

Scenario A — Response Manipulation

Backend
   ↓
401 Unauthorized
   ↓
Burp Suite
   ↓
401 → 200
   ↓
React

This may fool the client-side UI, because the browser is controlled by the attacker.

Scenario B — Actual Authorization Bypass 🚨

Expired / Revoked Token
        ↓
Protected API
        ↓
Backend Accepts Request
        ↓
Unauthorized Operation Executed

My primary concern is Scenario B.

Even if an attacker can manipulate the frontend or HTTP response, the backend should remain the final security boundary and must never perform an unauthorized operation.

🔟 What I Am Looking For

I would particularly appreciate feedback from people who have:

🛡️ Handled penetration-testing findings
🔐 Designed authentication/session architectures
☕ Implemented Spring Security
⚛️ Secured React applications
🏢 Built authentication systems for production applications

I’m interested in real-world solutions and architecture patterns, rather than only theoretical recommendations.

Tech Stack: ⚛️ React + ☕ Spring Boot + 🔑 JWT

Would appreciate any practical recommendations, security standards, or real-world experience with this type of security finding. 🙏

💬 Final Question

How would you design the authentication and authorization architecture so that a captured, expired, revoked, or previously terminated token can never be reused to perform a protected operation — even when the attacker controls the browser and uses Burp Suite to manipulate the HTTP traffic?

REST vs GraphQL vs gRPC — Which One Should You Really Use?

Vignesh Nagarajan — Wed, 17 Dec 2025 10:52:32 +0000

REST vs GraphQL vs gRPC — Which One Should You Really Use?

Every few months, the same question comes back:

“Which API style is best — REST, GraphQL, or gRPC?”

The honest answer is: there is no single best option.
Each one solves a different problem.

Let’s break it down without hype, based on real-world usage.

1️⃣ REST — The Reliable Default

REST is still the most widely used API style.

Why developers still choose REST

Simple and predictable
Human-readable JSON
Excellent tooling (Postman, curl, browser)
Easy caching and debugging
Works everywhere

Where REST struggles

Over-fetching data
Multiple API calls for complex UI screens

Example

GET /institutions/123/users

Best use cases

CRUD-heavy applications
Admin panels
Public APIs
Third-party integrations

2️⃣ GraphQL — UI-First APIs

GraphQL lets the client ask for exactly what it needs — no more, no less.

Why teams adopt GraphQL

No over-fetching or under-fetching
Single endpoint
Perfect for React / mobile apps
Strongly typed schema

Trade-offs

More complex backend
Caching is harder than REST
Needs careful authorization design

Example

query {
  institution(id: "123") {
    name
    users {
      name
      roles {
        name
      }
    }
  }
}

Best use cases

Frontend-heavy applications
Dashboards
Mobile apps
Aggregated UI data

3️⃣ gRPC — Built for Performance

gRPC is designed for service-to-service communication.

Why gRPC shines

Extremely fast (binary protocol)
Smaller payloads than JSON
Strong typing with Protobuf
Streaming support
HTTP/2 by default

Limitations

Not browser-friendly
Harder to debug manually
Requires contract-first thinking

Example (Proto)

rpc GetUser (UserRequest) returns (UserResponse);

Best use cases

Microservices
High-throughput systems
Internal APIs
Event streaming

4️⃣ The Best Architecture Is Hybrid (Not Religious)

In real production systems, teams don’t choose one — they combine them.

A common enterprise setup

Frontend (Web / Mobile)
        ↓
     GraphQL Gateway
        ↓
REST APIs     gRPC Services

Why this works

UI gets flexible data → GraphQL
Internal services stay fast → gRPC
External APIs remain simple → REST

5️⃣ Decision Cheat Sheet

Question	Choose
Public API?	REST
UI-driven data needs?	GraphQL
Microservice → Microservice?	gRPC
Performance critical?	gRPC
Simple CRUD?	REST

6️⃣ Common Mistakes to Avoid 🚫

Using GraphQL for everything
Using REST between internal microservices
Exposing gRPC directly to browsers
Ignoring caching and security implications

Final Thoughts

Each API style exists for a reason.

Good architecture is about using the right tool in the right place — not following trends.

If you’re building modern systems:

Use REST for simplicity
Use GraphQL for frontend efficiency
Use gRPC for internal performance

DEV Community: Vignesh Nagarajan

🔐 How to Prevent Expired JWT Token Reuse and API Authorization Bypass?

1️⃣ The Scenario

Expected behavior

2️⃣ The Interesting Part — Burp Suite

Flow

3️⃣ What I Have Already Considered

🔑 Authentication

🚫 Token / Session Management

👮 Authorization

4️⃣ Token Replay Scenario

5️⃣ Expected Security Model 🛡️

6️⃣ JWT vs Session-Based Authentication

7️⃣ Refresh Token Replay 🔄

8️⃣ My Questions to the Community ❓

9️⃣ The Important Distinction

Scenario A — Response Manipulation

Scenario B — Actual Authorization Bypass 🚨

🔟 What I Am Looking For

💬 Final Question

REST vs GraphQL vs gRPC — Which One Should You Really Use?

REST vs GraphQL vs gRPC — Which One Should You Really Use?

1️⃣ REST — The Reliable Default

Why developers still choose REST

Where REST struggles

Example

Best use cases

2️⃣ GraphQL — UI-First APIs

Why teams adopt GraphQL

Trade-offs

Example

Best use cases

3️⃣ gRPC — Built for Performance

Why gRPC shines

Limitations

Example (Proto)

Best use cases

4️⃣ The Best Architecture Is Hybrid (Not Religious)

A common enterprise setup

Why this works

5️⃣ Decision Cheat Sheet

6️⃣ Common Mistakes to Avoid 🚫

Final Thoughts