Authentication Testing Guide: How to Find OWASP A07 Vulnerabilities

OWASP A07 — Identification and Authentication Failures — covers a broad class of vulnerabilities that all share the same root problem: the application cannot reliably verify that a user is who they claim to be, or that an authenticated session remains controlled by the right person.

Authentication is the first gate. When it fails, everything behind it is exposed. Yet authentication testing is consistently under-scoped. Security assessments that spend days fuzzing API parameters often spend hours on login flows — the most targeted entry point for real-world attackers.

This guide covers the full surface area: credential security, brute force protections, session token analysis, JWT vulnerabilities, MFA weaknesses, password reset flows, and what automated tooling can and cannot detect.

What OWASP A07 Actually Covers

The OWASP Top 10 category renamed from "Broken Authentication" (2017) to "Identification and Authentication Failures" (2021) to capture a broader scope. The category now explicitly includes:

• Credential-based attacks — brute force, credential stuffing, password spraying
• Weak or default credentials in applications and infrastructure
• Weak password recovery flows (predictable tokens, no expiry, no rate limiting)
• Unprotected or predictable session identifiers
• Session management failures — no invalidation on logout, session fixation
• Multi-factor authentication weaknesses or absent MFA
• Credential exposure — storing passwords in plaintext or with weak hashing

These are not esoteric edge cases. Credential stuffing attacks process billions of username/password combinations leaked from prior breaches. Authentication bypass via session fixation is a category of vulnerability that appears in enterprise applications built by experienced teams.

Testing Credential Security

Password policy enforcement

Start at registration. What does the application actually enforce versus what it claims?

• Set a password of a — does the application accept single-character passwords?
• Set a password of password123 — does the application accept common passwords?
• Test maximum length — applications with a maxlength HTML attribute but no server-side check may silently truncate passwords, causing login failures with correctly-entered credentials
• Test character encoding — does the application strip or reject non-ASCII characters in passwords?
• Check if the policy is enforced server-side, not just client-side JavaScript

The test for common passwords is particularly important. The NIST SP 800-63B guidelines explicitly recommend blocking passwords on known-compromised password lists. Many applications have minimum length and complexity rules but nothing that prevents Password1! from being accepted.

Brute force protection

A login form with no rate limiting is a direct invitation to credential stuffing. Test the following:

• Send 50 rapid requests with wrong credentials — is there any lockout, CAPTCHA, or rate limit response?
• Test lockout behavior — is the lockout per-account, per-IP, or both? IP-based lockout alone is trivially bypassed with rotating proxies
• Check the X-Forwarded-For and X-Real-IP headers — if the application uses these for IP tracking, injection of a spoofed IP may bypass IP-based lockout
• Test lockout duration — is there an account recovery path if a legitimate user gets locked out?
• Test whether the lockout applies to API endpoints as well as the web form — the JSON endpoint at /api/auth/login may have different (or no) protection

Username enumeration

Many applications inadvertently reveal which usernames exist through their error messages, response times, or HTTP status codes:

• Error messages — "Invalid password" versus "User not found" is explicit enumeration
• Response timing — some implementations do a database lookup for valid users and skip it for invalid ones, creating a measurable timing difference even with identical error messages
• Password reset flow — "We've sent a reset email to that address" versus "No account found" reveals account existence
• Registration — "That email is already registered" reveals existing accounts

The correct behavior is consistent responses regardless of whether the username exists. For password reset, the NIST recommendation is to always respond with "If an account exists with that email, a reset link has been sent" — this prevents enumeration without misleading users.

Session Token Analysis

Once authentication succeeds, the application issues a session token. The security of the session depends entirely on the quality of that token.

Token entropy and predictability

Collect 20–50 session tokens and analyze them:

• Length — tokens under 128 bits of entropy are insufficient for modern threat models
• Encoding patterns — base64-decode tokens and inspect the raw bytes; sequential user IDs encoded in base64 are not session tokens, they're a broken access control vulnerability
• Timestamp components — tokens that incorporate creation time can be narrowed down with timing attacks if entropy is insufficient
• Incremental or patterned tokens — sort the tokens you collected; if they show predictable ordering, the token space can be enumerated

Use Burp Suite's Sequencer to statistically analyze token randomness. It will calculate FIPS 140-2 test results and highlight specific bit positions that show low entropy.

Cookie security attributes

For session cookies, check every attribute:

Session lifecycle

A session token that never expires is a long-term credential that provides persistent access long after the user stops actively using the application. Test:

• Logout invalidation — after logging out, is the old session token still accepted? Submit a request with a logged-out session token and verify the server returns 401, not a valid response
• Password change — after changing a password, are all existing sessions invalidated? (Prevents session continuation after a compromised account's password is reset)
• Inactivity timeout — is there an idle session timeout separate from absolute expiry?
• Re-use of old tokens — after logout and re-login, are old tokens still valid? The server must invalidate server-side, not just delete the client cookie

Session fixation

Session fixation occurs when an application accepts a session ID that was set before authentication, rather than issuing a new one after successful login. The attack:

1. Attacker visits the application and gets a valid (unauthenticated) session ID
2. Attacker tricks a victim into clicking a URL or loading a page that sets that session ID in the victim's browser (via URL parameter, JavaScript, or subdomain cookie injection)
3. Victim authenticates — the application now associates the known session ID with the victim's identity
4. Attacker uses the known session ID to access the victim's authenticated session

Test by extracting your pre-login session token, completing authentication, and checking whether the post-login token is a new value or the same one. If it's the same value, session fixation is confirmed.

JWT Vulnerabilities

JSON Web Tokens (JWTs) are widely used for authentication and authorization. They introduce a distinct class of vulnerabilities separate from traditional session cookies.

Algorithm confusion attacks

The original "alg:none" attack allowed JWTs with the algorithm set to none to be accepted without signature verification. Modern libraries have patched this, but the broader algorithm confusion class persists:

• RS256 → HS256 confusion — if a server uses RS256 (asymmetric), the public key is available. Attackers forge a token signed with HS256 using the public key as the secret. If the server doesn't enforce the expected algorithm, it will verify the HS256 token using the public key as the HMAC secret — and succeed.
• Header injection — the kid (key ID) and jku/jwks (key URL) header parameters specify where to find the signing key. If an application fetches keys from a URL controlled by the jku header without validation, an attacker can supply a key they control and forge tokens.
• Embedded JWK attack — some implementations accept a key embedded directly in the JWT header via the jwk parameter and use it for verification, which is equivalent to accepting tokens signed with any key.

Tools: Burp Suite's JWT Editor extension and jwt.io for manual inspection. For automated testing, jwt_tool covers most known JWT attack vectors.

Claim manipulation

If signature verification is absent or weak, payload claims can be modified directly:

• Change "role": "user" to "role": "admin"
• Change "sub": "42" to another user ID
• Extend the exp claim to create non-expiring tokens
• Add claims the application uses for authorization decisions

The test: decode the JWT, modify a claim, re-encode without changing the signature, and see if the application accepts it. If it does, signature verification is not functioning.

Weak signing secrets

HS256 JWTs signed with weak secrets (short strings, default values like secret, jwt, or the application name) can be cracked offline once you have a valid token. Tools like jwt-cracker or hashcat with the JWT-HMAC mode can brute-force short secrets against wordlists.

Extract a valid JWT and run it through a wordlist attack. Common weak secrets found in the wild: secret, password, changeme, the application's domain name, and values from leaked configuration files.

Multi-Factor Authentication Testing

MFA reduces the impact of stolen credentials, but implementation flaws are common.

OTP bypass through response manipulation

Some applications implement MFA client-side or with weak server-side verification. Test:

• Intercept the MFA verification response and manipulate the server's response from {"success": false} to {"success": true} — if the application uses the response to drive navigation rather than server-side session state, this bypasses MFA entirely
• Submit an empty OTP, a null value, or a string of zeros — some implementations have edge cases in their validation logic
• Skip the MFA step entirely by navigating directly to the post-authentication URL — if there's no server-side check for MFA completion, forced browsing bypasses it

Rate limiting on OTP codes

A six-digit TOTP code has only one million possible values. Without rate limiting, it can be brute-forced online in minutes. Test:

• Rapidly submit all codes from 000000 to 999999 (or a subset) and observe whether rate limiting kicks in
• Check whether the rate limiting is per-session, per-IP, or per-account
• Test whether there's a lockout on repeated MFA failures, separate from the credential lockout

MFA fatigue (push notification attacks)

Applications using push-based MFA (Authenticator apps that send approve/deny prompts) are vulnerable to notification fatigue. An attacker with stolen credentials can trigger repeated push notifications until a user mistakenly approves one. Test:

• Trigger multiple MFA push notifications in rapid succession
• Verify whether the application limits push notification frequency
• Check whether the notification includes context (location, device) that would help users identify unauthorized attempts

Backup code handling

Backup codes are single-use recovery credentials. Test whether they are truly single-use, whether they have appropriate entropy, and whether they can be brute-forced due to absent rate limiting on backup code submission.

Password Reset Flow Vulnerabilities

Password reset flows are a secondary authentication path — and often less carefully tested than the primary login.

Predictable or weak reset tokens

Request multiple password reset tokens and analyze them:

• Are tokens based on timestamps, user IDs, or other predictable values?
• Do tokens contain the user's email or username in encoded form?
• Are tokens sufficiently long (minimum 128 bits of entropy)?
• Are tokens time-limited — can a token from an hour ago still be used?
• Can a token be reused after it has been consumed?

Token delivery and handling

• Is the reset token sent as a URL parameter (visible in server logs, browser history, Referer headers)?
• Is the token invalidated when the user logs in through normal means?
• Is the old password immediately invalidated when the reset flow begins, or only after completion?
• Can an attacker initiate a reset for a victim's account and monitor network traffic for the token (if the application leaks it in a redirect or referrer)?

Host header injection in reset emails

Some applications construct the password reset URL using the HTTP Host header. If the application trusts the Host header without validation:

POST /password-reset HTTP/1.1
Host: attacker.com

email=victim@example.com

The reset email may be sent with a link pointing to attacker.com. When the victim clicks it, the reset token goes to the attacker's server. Test by manipulating the Host header and checking whether the generated reset URL reflects the injected value.

What Automated Scanning Catches

Automated tools are effective for a subset of authentication testing. Knowing what they find — and what they miss — helps you plan the manual testing scope.

The pattern holds across most security testing: automated tools are reliable for structural checks (cookie flags, basic rate limiting, common token attacks) and unreliable for business logic vulnerabilities that require understanding the application's intended flow.

Testing Checklist

Before signing off an authentication test:

• Test password policy enforcement server-side, including common password rejection
• Attempt brute force against login endpoint — verify lockout triggers and IP-based bypass doesn't work
• Test username enumeration via login, registration, and password reset endpoints
• Analyze 20+ session tokens for entropy and predictability (use Burp Sequencer)
• Verify all session cookie security attributes: Secure, HttpOnly, SameSite
• Confirm session invalidation on logout — replay the token after logout and verify 401
• Confirm session invalidation on password change
• Test session fixation — compare pre- and post-authentication token values
• For JWT applications: test alg:none, RS256→HS256 confusion, kid injection, and run against common weak secret wordlists
• Test MFA bypass: forced browsing to post-auth URLs, response manipulation, rate limiting on OTP
• Analyze password reset tokens for entropy, expiry, and single-use enforcement
• Test Host header injection in password reset flows
• Verify account lockout does not leak account existence through different error messages

Remediation Priorities

When authentication vulnerabilities are found, prioritization should be:

1. Critical: Broken session invalidation on logout, session fixation, JWT signature bypass, MFA bypass via forced browsing — these allow attackers to maintain persistence in accounts they should not have access to
2. High: Missing rate limiting on login and password reset, username enumeration, weak password reset tokens, missing HttpOnly flag (enables XSS-based session theft)
3. Medium: Missing SameSite attribute (requires CSRF context), no inactivity timeout, weak password policy enforcement
4. Low/Informational: Verbose error messages that reveal stack traces, missing Secure flag on non-sensitive cookies

Authentication fixes often require coordination between frontend and backend teams. Session management changes (particularly logout invalidation and token rotation) can introduce regressions in single-page applications where session state is managed client-side. Test regression paths carefully after any session management changes.