Token Not Invalidated on Logout
JWT or session tokens remain valid after a user logs out because there is no server-side revocation mechanism, allowing stolen tokens to be used indefinitely.
How It Works
Stateless JWTs have no built-in revocation. Logging out on the client (deleting the token from memory or localStorage) is meaningless if the server will still accept that token. An attacker who captured the token before logout can continue using it until it expires — which could be hours, days, or never.
// BAD: logout just clears client-side storage
export async function POST() {
// Just tells the client to delete the token
// But the token itself is still valid server-side
return Response.json({ message: 'Logged out' });
}// GOOD: maintain a token denylist in Redis
import { redis } from '@/lib/redis';
export async function POST(req: Request) {
const token = req.headers.get('authorization')?.split(' ')[1];
if (token) {
const decoded = jwt.decode(token) as { exp: number };
const ttl = decoded.exp - Math.floor(Date.now() / 1000);
if (ttl > 0) await redis.setex(`denylist:${token}`, ttl, '1');
}
return Response.json({ message: 'Logged out' });
}Real-World Example
Any app that stores JWT tokens (mobile apps, browser extensions, third-party integrations) is vulnerable. If a user logs out on their phone after suspecting compromise, the attacker's copy of the token is still valid. Supabase handles this automatically — rolling your own JWT auth is where this bites you.
How to Prevent It
- Maintain a token denylist in Redis with TTL equal to the token's remaining lifetime
- Use short-lived tokens (15 minutes) to minimize the window between logout and token expiry
- For session-based auth, invalidate the server-side session record on logout
- Consider using Supabase Auth or Auth.js which handle session invalidation correctly
Affected Technologies
Data Hogo detects this vulnerability automatically.
Scan Your Repo FreeRelated Vulnerabilities
Session Fixation
highThe server reuses the same session ID before and after login, allowing an attacker who planted a known session ID to hijack the authenticated session.
No Account Lockout / Brute Force Protection
mediumLogin endpoints with no rate limiting or lockout mechanism, allowing attackers to try unlimited username and password combinations until they find valid credentials.
Weak Password Policy
mediumNo minimum length, complexity, or common-password requirements on registration or password change, making user accounts easily brute-forced or guessed.
OAuth State Parameter Missing
highOAuth authorization flow implemented without a random `state` parameter, allowing CSRF attacks that link a victim's account to the attacker's OAuth identity.