Readiness guide · Authentication / JWT bypass

Why authentication-bypass bug-bounty reports get marked N/A — and how to prove real impact

Auth-bypass findings are high-severity when they open a door and worthless when they only rattle the handle. Most rejections stop at the token weakness.

← All readiness guides

Why triagers mark it N/A

• Token weakness with no access. “The server accepts alg:none” is a finding component. Without using it to reach something you shouldn’t, it is often informational.
• Forged token, unprivileged result. Crafting an admin token the app then treats as a normal user proves nothing — the authorization check may still hold server-side.
• Self-account only. Escalating within your own account, or accessing data you already own, isn’t a bypass.
• Theoretical replay/expiry. “Tokens don’t expire” without a demonstrated takeover is usually low or informational.

What proof actually looks like

Use the weakness to access a protected resource or act as a higher-privileged principal — reach an admin-only surface, read another user’s protected data, or perform an action your role shouldn’t allow. Show the forged/altered token and the protected response it unlocked, proving the check is actually bypassed, not just malformed input being accepted.

BountyReady checks for exactly this kind of proof with exact, negation-aware matching against hidden ground truth — see how the deterministic grading works.

Before you submit — checklist

• Did you reach a protected resource or privileged action, not just get a forged token accepted?
• Is the accessed resource someone else’s or above your privilege level?
• Did you show the token and the protected response it unlocked?
• Is the impact concrete (“accessed the admin console / another user’s data”), not “JWT is not verified”?
• Reproducible, in scope, and non-destructive?

Other readiness guides

• IDOR / BOLA — readiness guide
• Server-Side Request Forgery — readiness guide
• Cross-Site Scripting — readiness guide
• SQL Injection — readiness guide