Authentication Security Audit Checklist for Web Applications

Most authentication vulnerabilities are not novel. They are the same category of mistakes — weak session configuration, tokens stored in the wrong place, no rate limiting on the login endpoint — that appear repeatedly across applications of every scale. A structured audit catches them before attackers do.

Use this checklist when reviewing a new codebase, onboarding a security review, or shipping a significant auth change.

Before You Start: Scope the Audit

Before running through the checklist, identify everything that touches authentication in the application:

• All login, logout, and session endpoints
• Token issuance and verification code
• Password reset and account recovery flows
• Third-party auth integrations (OAuth, SAML, OIDC)
• Any admin or elevated-privilege access paths

Do not limit the review to the auth service. Permission checks scattered through business logic are also in scope.

Authentication Security Audit Checklist

Session Management

• HTTP-only cookies. Session identifiers and auth tokens stored in browser-accessible storage (localStorage, sessionStorage) are vulnerable to XSS. Verify tokens and session IDs are in HttpOnly cookies.
• Secure flag. Cookies must have Secure set so they are never sent over plain HTTP.
• SameSite attribute. SameSite=Lax prevents cross-site request forgery for most cases. Use Strict for highly sensitive operations.
• Session ID length. Session IDs must be at least 128 bits of cryptographically random data. Short or predictable IDs are guessable.
• Session regeneration on privilege change. Issue a new session ID after login, role change, or privilege escalation. Failing to do so enables session fixation attacks.
• Session expiry. Idle and absolute timeouts must be configured. Sessions that never expire are a persistent risk.
• Logout invalidates server-side state. Logout must delete the session on the server, not just clear the cookie. Clearing the cookie alone does not prevent session reuse by an attacker who captured it.

Password Handling

• Passwords are hashed with a proper algorithm. Bcrypt, Argon2id, or scrypt. Not MD5, SHA-1, or unsalted SHA-256.
• Salting is per-user. Each password hash must include a unique salt. Verify your hashing library handles this automatically (most do).
• No password length truncation. Some older implementations silently truncate passwords at 72 characters or similar limits. Verify there is no silent truncation.
• Password reset tokens are single-use. A reset link should be invalidated immediately after use, not after a time window.
• Password reset tokens have a short TTL. 15-60 minutes is the practical range. Tokens valid for 24 hours or more are too long.
• Reset emails do not leak account existence. The response to a reset request for a nonexistent email should be identical to the response for an existing one.

Token Security (JWT and OAuth)

• Algorithm is hardcoded server-side. The alg field in a JWT header must never be trusted. The server must specify the expected algorithm.
• The none algorithm is explicitly rejected.
• Tokens are not stored in localStorage.
• Token expiry is configured and enforced. Verify exp is present and checked.
• Audience and issuer claims are validated. iss and aud must match expected values.
• Refresh tokens are rotated on use. Reuse of an old refresh token should trigger an alert and invalidate the session.
• Signing secrets are sufficient length. HMAC secrets should be at least 256 bits of random data. RSA keys should be at least 2048 bits.

Multi-Factor Authentication

• MFA is available. At minimum, TOTP (app-based) should be supported.
• MFA is enforced for privileged accounts. Admin users and service accounts should be required to use MFA.
• TOTP implementation uses a constant-time comparison. Timing attacks on TOTP codes are theoretical but worth preventing.
• Recovery codes are provided and single-use.
• MFA cannot be bypassed via account recovery. A common oversight: the password reset flow bypasses MFA entirely, making MFA theater.

Rate Limiting and Brute-Force Protection

• Login endpoint is rate-limited. By IP, by account, or both.
• Password reset endpoint is rate-limited. An unprotected reset endpoint enables email flooding and account enumeration.
• Account lockout or progressive delay is implemented. Repeated failed logins should trigger a lockout or increasing delay.
• CAPTCHA or proof-of-work for repeated failures. For consumer-facing apps, a CAPTCHA after a threshold of failed attempts reduces automated attacks.
• OAuth callback endpoint is protected. Unprotected callback endpoints can be abused for denial-of-service.

OAuth and Third-Party Auth

• Redirect URIs use exact matching. No wildcards, no prefix matching.
• State parameter is generated and verified per request.
• PKCE is used for all public clients.
• Scopes are minimal. The application requests only the scopes it actually uses.
• ID token claims are fully validated (signature, iss, aud, exp, nonce).

Account Recovery

• Recovery links are delivered only to verified channels. The email address or phone number must be confirmed before it can be used for recovery.
• Recovery does not downgrade security. Completing account recovery should not permanently disable MFA or other security controls.
• Admin-assisted recovery is logged and audited.

Logging and Monitoring

• Authentication events are logged. Successful logins, failed logins, password changes, MFA events, and logout should all produce log entries.
• Logs do not contain sensitive values. Passwords, tokens, and session IDs must never appear in log output.
• Alerts are configured for suspicious patterns. Multiple failed logins from a single IP, bulk password reset requests, logins from new geographies.

How to Use This Checklist

Walk through it systematically with access to both the codebase and the running application. For each item, mark it as passing, failing, or not applicable, and document the specific finding for failing items. Prioritize session management and password handling first — those categories contain the issues that lead to full account compromise.

An authentication audit is not a one-time exercise. Run it at launch, after significant auth changes, and on a scheduled cadence for production systems handling sensitive data.

If you need an expert authentication review or a complete auth rebuild on a compressed timeline, Clixo works with product teams who need it done right.