A fully manual security assessment of three broken-authentication bugs — no scanners, just a proxy-backed browser and raw HTTP evidence, mapped end-to-end to CWE and OWASP. ⚠️ Educational / authorized testing only.
Everything below targets a local, deliberately vulnerable training application, not a live system.
Never run these techniques against anything you don't own or don't have explicit written authorization to test.
Automated scanners are great at pattern-matching known vulnerability classes.
They're much weaker at authentication flaws that look completely legitimate at the HTTP level — a 200, a 401, a token — and only become a bug once you understand how the value was generated.
This walkthrough is a fully manual assessment of three such bugs in a deliberately vulnerable login system, captured start to finish with nothing but a proxy-backed browser and a network tab.
The bugs # Bug CWE OWASP 1 has no rate limit, delay, or lockout CWE-307 A07:2021 – Identification and Authentication Failures 2 Session tokens are sequential integers, not random CWE-330 A07:2021 3 Password-reset token is — deterministic, not random or single-use CWE-640 A07:2021 Phase 1 — No brute-force protection Three wrong passwords for , back to back, then the real one.
All four requests return instantly — no , no CAPTCHA, no increasing delay.
Filtering the network tab down to shows the whole sequence sitting there in plain sight: nothing on the server side ever notices the repetition.
That's the entire proof for CWE-307.
A real attacker isn't limited to four guesses — they're limited by whatever rate their network connection allows, because the server places no limit of its own.
Phase 2 — Predictable session tokens The login endpoint hands out tokens from a shared, incrementing counter — regardless of which account is logging in. gets . gets .
That's already suspicious, but the real proof of impact is this: clear your cookies, open a private window, and request with zero credentials.
The server hands back 's full identity, because "knowing a number" and "being alice" are treated as equivalent.
Phase 3 — A reset token that isn't a secret returns a 32-character hex string that looks random — until you request it again and get the exact same value back.
It's not a secret; it's , a pure function of public data.
Anyone who knows a username can compute their "reset token" offline, with no server interaction and no account access at all.
From evidence to finding Each bug was routed from the network capture into a manual finding — evidence field populated with the actual request/response pairs, CWE and OWASP mapping attached, and a concrete fix: Finding A (Medium) — add per-account and per-IP throttling with exponential backoff or lockout, plus a CAPTCHA after repeated failures.
Finding B (High) — issue tokens from a cryptographically secure random source (128+ bits), never a counter.
Finding C (High) — generate a random, single-use, time-limited reset token, stored server-side and delivered only to the account's verified contact method.
Takeaway None of this required exploit tooling — it required patience, a network tab, and the discipline to capture evidence before writing a single conclusion.
Scanners are excellent at known-signature bugs; deterministic secrets and predictable state are exactly the class of finding that still needs a human reading raw traffic.
What's the last "boring" auth bug your team caught that a scanner missed?
Curious to hear how others are covering this gap.
Try it yourself → https://github.com/sendwavehub/scan-target-demo-apps Windows Store https://apps.microsoft.com/detail/9pj0j7bk1m27?hl=en-US Web Site https://Sendwavehub.tech/en/apps/ai-security-studio-4