Broken Authentication in Web Apps — What It Is and How to Test for It
Broken Authentication in Web Apps — What It Is and How to Test for It
TLDR: The attacker didn't know the password. They didn't need to. The password reset link the application sent didn't expire. They found it in the user's email — sent three days earlier — clicked it, and reset the password to their own. Account owned. No hacking required. Broken authentication is one of the most consistently exploited vulnerability categories I test — and it almost never comes down to weak passwords. It comes down to the dozen small decisions made during implementation that each introduce a gap an attacker can walk through.
What "Broken Authentication" Actually Means
Most people hear "broken authentication" and think "weak passwords." That's one small piece of a much broader category.
Authentication is the entire system by which your application establishes and maintains identity — not just the login form, but everything that follows it. How sessions are created, stored, and invalidated. How password resets are handled. How multi-factor authentication is implemented. How "remember me" tokens work. How the application responds to repeated failed login attempts.
A flaw in any part of this system is a broken authentication vulnerability. The OWASP Top 10 lists it under A07 — and while its ranking has shifted over the years as the category has been refined, its prevalence in real-world assessments hasn't changed significantly. I find meaningful authentication flaws in the majority of web applications I test, across every tech stack and company size.
The 7 Things I Test in Every Authentication Implementation
1. Session Token Randomness and Length
When a user logs in, the application creates a session token — a credential that proves identity for the duration of the session. If that token is short, predictable, or based on something guessable (a timestamp, a sequential number, an MD5 of the username), an attacker can forge or brute-force it without ever knowing the password.
I test this by examining token length, entropy, and structure. A session token should be cryptographically random, at least 128 bits of entropy, and contain no encoded user information that could be manipulated.
2. Session Invalidation on Logout
When a user clicks logout, does their session token actually stop working? In a surprising number of applications, the answer is no. The frontend clears the cookie. The backend keeps the session valid. An attacker who captured the token earlier — through network interception, an XSS vulnerability, or physical access to a device — can continue using it indefinitely.
Testing this is straightforward: capture a valid session token, log out, attempt to use the captured token to make authenticated API requests. If requests succeed, the session isn't being invalidated server-side.
3. Password Reset Flow
Password reset is one of the most attack-prone areas of any authentication implementation. I test four things specifically:
Token expiry — reset links that don't expire within a short window (15–60 minutes is standard) remain usable long after they should be invalid, as in the opening example.
Single-use enforcement — a reset token should be invalidated immediately after use. If it can be used multiple times, an attacker who intercepts it can reset the password again after the victim has already used it.
User enumeration — if the reset form returns "that email doesn't exist" for unknown addresses and "reset email sent" for known ones, an attacker can enumerate your entire user database one email address at a time. The response should be identical regardless of whether the address exists.
Token predictability — reset tokens must be cryptographically random. Generated timestamps, base64-encoded usernames, or sequential values are all exploitable.
4. Brute Force Protection
A login endpoint with no account lockout or rate limiting is an open invitation to credential stuffing — automated tools cycling through leaked username/password combinations from other breaches against your login endpoint. At scale, even a 0.1% success rate across millions of attempts harvests thousands of valid credentials.
I test lockout behaviour (does it trigger? at what threshold? does it lock account or IP or both?), lockout bypass (rotating IPs, distributing attempts across time), and CAPTCHA implementation if present. Many CAPTCHA implementations can be bypassed or simply aren't applied consistently across all login endpoints.
5. MFA Implementation and Bypass
Multi-factor authentication significantly raises the bar for attackers — but only if it's implemented correctly. The gaps I find most frequently:
OTP reuse — time-based one-time passwords (TOTP) that can be used multiple times within their validity window, or after the window has closed.
No rate limiting on OTP submission — an attacker who has a valid username and password can brute-force a 6-digit OTP in under 17 minutes if there's no throttling on the verification endpoint.
MFA bypass via account recovery — a well-implemented MFA can be rendered irrelevant by a weak account recovery flow that allows complete account takeover without the second factor.
MFA not enforced on all entry points — applications that require MFA on the web login but not on API authentication, mobile endpoints, or legacy access paths leave the second factor easily circumvented.
6. Remember-Me Token Security
"Remember me" functionality creates a long-lived credential that persists beyond the session. If this token is the same as the session token (or derivable from it), is stored without secure cookie flags, or doesn't have its own invalidation mechanism, it creates a persistent attack surface that survives password resets.
A properly implemented remember-me token should be a separate, cryptographically random value stored server-side, with its own expiry, and invalidated when the user explicitly logs out from all devices.
7. Credential Stuffing Resistance
Credential stuffing — using username/password pairs leaked from other breaches against your application — is one of the highest-volume automated attacks in 2025. Resistance to it involves a combination of rate limiting, IP reputation checking, behavioural analysis, and — most effectively — prompting users with compromised credentials to change their password.
Have I Been Pwned provides a free API that allows applications to check whether a submitted password appears in known breach datasets at registration and login time. This is a straightforward integration with meaningful impact.
Rolling Your Own Auth vs. Using a Trusted Provider
Every one of the seven areas above represents a decision point during authentication implementation — and each is an opportunity to introduce a vulnerability. Authentication is genuinely one of the most security-sensitive areas of any application, and implementing it correctly from scratch requires significant expertise and ongoing maintenance.
For most startups, the case for using a managed authentication provider is strong. Services like Auth0, Clerk, and Supabase Auth handle session management, token security, MFA, credential stuffing resistance, and password reset flows to a standard that most custom implementations don't match — and they absorb the maintenance burden as security standards evolve.
The trade-off is vendor dependency and, at scale, cost. But for an early-stage product where authentication isn't a differentiating feature, offloading it to a purpose-built provider eliminates an entire category of security risk.
If you are rolling your own authentication — because your requirements genuinely demand it — use a well-maintained library for your stack rather than building primitives yourself. Passport.js for Node, Devise for Rails, django-allauth for Django. The hard problems have been solved. Use the solutions.
Get Your Authentication Implementation Reviewed
Authentication flaws are among the highest-impact vulnerabilities in any web application — they're the difference between an attacker being locked out and an attacker having access to every account on your platform.
A focused authentication review examines all seven areas above against your specific implementation: your session handling, your reset flow, your MFA setup, your brute force controls. The findings are specific, prioritised, and come with remediation guidance your development team can act on directly.
If you're unsure whether your authentication holds up under scrutiny, get in touch — that's exactly the kind of question we're here to answer. You can also review our full services offering or read more about how we work.
More practical security guides on the Kuboid Secure Layer blog.
