Audit a JWT authentication setup: common pitfalls and fixed code
Check your JWT implementation against the usual mistakes (algorithms, expiry, storage, refresh tokens, revocation) and get severity-ranked findings, corrected code and tests. Designed for ChatGPT, Claude, Gemini and Microsoft Copilot. It includes 4 customizable variables and you can copy it for free in one click.
Advanced · Code · Pending editorial review
Prompt
Act as an application security engineer specializing in API authentication.
Review this JWT authentication implementation:
{{code}}
Context:
- Stack and JWT library: {{stack}}
- Client type: {{client}}
- Who issues the tokens: {{issuer}}
Deliverables:
1. Findings with severity (critical, high, medium, low), affected snippet, the risk in one sentence and the fix. Check at least:
- Signature verification with an explicit allowlist of algorithms; rejection of `alg: none` and of symmetric/asymmetric algorithm confusion.
- Validation of `exp`, `nbf`, `iss` and `aud`, with a small clock-skew allowance.
- Access token lifetime, and refresh tokens with rotation and reuse detection.
- Revocation and logout: denylist, session version or short-lived tokens.
- Client storage: `localStorage` vs an `HttpOnly`, `Secure`, `SameSite` cookie, and the CSRF protection each option requires.
- Secrets and keys: strength, where they are stored, rotation with `kid` or JWKS.
- Sensitive data in the payload (which is only encoded, not encrypted) and token size.
- Error handling: messages that do not leak information and logs without full tokens.
2. Corrected code for my stack, using a maintained library and no hand-rolled crypto.
3. Automated tests for every critical or high finding: expired token, invalid signature, disallowed `alg`, wrong audience and reused refresh token.
4. A fix priority order in case I cannot do everything at once.
Constraints:
- Do not claim the system is now fully secure; recommend a security review or penetration test before production if it handles sensitive data.
- If part of the flow is missing (issuing, refresh or logout), ask me before concluding or mark it as [FILL IN].
- Never repeat real secrets that appear in the code: replace them with placeholders.How to use it
- Paste the code for issuing, verifying, refreshing and logging out, replacing any real secrets first.
- Say what kind of client consumes the API and where it keeps the token.
- Fix the critical findings first and add their tests to your CI.
Usage example
Stack: Node.js with Express and jsonwebtoken · Client: SPA on another subdomain · Issuer: the API itself · Code: auth middleware and the /refresh endpoint.
Sample output
1. Findings
| Severity | Snippet | Risk | Fix |
|---|---|---|---|
| High | jwt.verify(token, secret) | No explicit algorithm allowlist: you rely on library defaults | algorithms: ['HS256'] |
| High | — | iss and aud are not checked: a token issued for another service is accepted | issuer and audience |
| Medium | req.user = payload | The whole payload is trusted | Copy only sub and role |
| Medium | — | verify throws and nothing catches it | try/catch and a generic 401 |
| [FILL IN] | — | Issuing, refresh and logout are not shown | I need that code |
2. Corrected code
const jwt = require('jsonwebtoken');
const VERIFY_OPTS = {
algorithms: ['HS256'], // never trust the token's own alg header
issuer: 'https://api.example.com', // [FILL IN]
audience: 'example-spa', // [FILL IN]
clockTolerance: 30, // seconds of clock skew
};
function requireAuth(req, res, next) {
const token = req.cookies?.access_token; // HttpOnly, Secure, SameSite cookie
if (!token) return res.status(401).json({ error: 'unauthorized' });
try {
const { sub, role } = jwt.verify(token, process.env.JWT_SECRET, VERIFY_OPTS);
req.user = { id: sub, role };
return next();
} catch {
return res.status(401).json({ error: 'unauthorized' }); // no details to the client
}
}
Reading the token from a cookie requires cookie-parser and CSRF protection on state-changing routes…
Key facts
- Category
- Programming & development · APIs
- Output type
- Code
- Level
- Advanced
- Designed for
- ChatGPT, Claude, Gemini and Microsoft Copilot
- Verified in
- Pending editorial verification
- Variables
- Current code, Stack and library, Client type and Token issuer
- Language
- English
- Price
- Free, no sign-up
- Updated
- Nov 7, 2026
Frequently asked questions
Should I store the JWT in localStorage or a cookie?
localStorage is exposed if you have an XSS vulnerability. An HttpOnly cookie cannot be read by JavaScript, but it needs CSRF protection and a correct SameSite setting. The prompt explains what each option means for your case.
How do I log users out if JWTs cannot be invalidated?
Use short-lived access tokens with server-side revocable refresh tokens, or store a per-user session version checked on each request. That lets you cut access without waiting for the token to expire.
What is this prompt for?
Check your JWT implementation against the usual mistakes (algorithms, expiry, storage, refresh tokens, revocation) and get severity-ranked findings, corrected code and tests.
Which AI tools does it work with?
It is designed for ChatGPT, Claude, Gemini and Microsoft Copilot. We have not verified it in these tools yet, so results may vary between them.
How do I customize the prompt?
Click “Customize” and fill in the variables (Current code, Stack and library, Client type and Token issuer). The text updates instantly and you can then copy it in one click. Values are stored only in your browser.
Do I need experience to use it?
It is advanced: it is meant for people with experience in the topic who can evaluate and adjust the result.
Is this prompt free?
Yes. Every HomeCasa Prompts prompt is free, with no sign-up or subscription. You can also use them in professional projects.
Can I trust the AI output?
Treat it as a high-quality draft: always check data, figures and important claims before publishing or making decisions.