Auth bugs QA can catch without being a pentester
The auth and session bugs that show up in normal functional testing — no exploit tooling required.
Blog
Auth, sessions, permissions, and the security-adjacent bugs QA can catch during normal functional testing.
The auth and session bugs that show up in normal functional testing — no exploit tooling required.
Password reset is a deceptively risky flow — token reuse, expiry, enumeration, and session handling all hide here.
The most common serious web vulnerability is also the easiest for QA to catch: the app serves a record by ID without checking it is yours. Two accounts and a changed number find it.
Authentication asks who you are; authorization asks if you are allowed. Most access-control bugs live in the second question — tested with a written access matrix and a lot of negative testing.
A session that lives too long is a hole, one that survives logout defeats the point. Here is the session-expiry pass — idle, absolute, logout, reset, remember-me, and fixation.
The OWASP Top 10 translated for QA: what each category means for flows you already test, and the one check you can run without being a pentester.
The full multi-factor auth test surface: bypass, wrong/expired/reused codes, brute-force lockout, recovery, and the usability cases most teams skip.
A green suite, a flawless demo, and a permission check enforced in the UI but not the API — exposing every customer's data. Caught the day before release.
Treat the auth token as an input: test that it expires, dies on logout, can't cross scope or user, doesn't leak, and rejects tampering — all with your normal API client.
A security report has extra duties: private channel, impact over exploit, test data only, redacted evidence, clear severity — getting it fixed without making it worse.