Skip to content

CWE-287: Improper Authentication

Overview

Improper authentication occurs when an application fails to correctly verify the identity of users, services, or systems. Unlike weak passwords or credential stuffing (which exploit credential weaknesses), improper authentication represents flaws in the authentication logic itself - the mechanism that validates "you are who you claim to be." This allows attackers to bypass authentication entirely, impersonate legitimate users, gain unauthorized access, or escalate privileges.

OWASP Classification

A07:2025 - Authentication Failures

Risk

Improper authentication creates critical security exposures:

  • Unauthorized access: Attackers access accounts, data, or functions without valid credentials
  • Account takeover: Bypass authentication to fully control user accounts
  • Unauthorized identity establishment: Impersonate another user or service before authorization checks run
  • Data breaches: Access sensitive information belonging to other users
  • Compliance violations: Fails SOX, PCI-DSS, HIPAA, GDPR authentication requirements
  • Business logic bypass: Access payment, ordering, or workflow functions without authenticating
  • API abuse: Exploit unauthenticated or weakly authenticated API endpoints

In regulated industries or applications handling sensitive data, authentication failures can trigger mandatory breach disclosure and significant penalties.

Common Authentication Failures

Authentication vulnerabilities manifest in several ways:

  • Missing authentication on critical functions: Admin panels, APIs, or sensitive operations accessible without login
  • Weak or predictable authentication tokens: Session IDs, JWT secrets, or API keys easily guessed or brute-forced
  • Authentication bypass through trusted client state: Accepting user IDs, roles, or login flags from request parameters, cookies, or headers without server-side validation
  • Insecure "remember me" functionality: Persistent tokens that never expire or can be stolen
  • Session fixation vulnerabilities: Attacker sets known session ID before user authenticates
  • Inadequate protection against automated attacks: No rate limiting, CAPTCHA, or account lockout mechanisms

Remediation Steps

Core principle: Never trust client-supplied identity; every request must be authenticated by the server using a complete, validated authentication mechanism before any identity or session is accepted.

Trace authentication flows and identify weaknesses

  • Authentication Entry Points: Identify all authentication mechanisms (login forms, API auth, SSO, OAuth, password reset)
  • Verification Logic: Examine how credentials are validated - look for bypass conditions
  • Session Management: Review session token generation, storage, timeout, and invalidation
  • Protected Resources: Identify which endpoints/functions require authentication
  • Missing Protections: Find resources lacking authentication checks, especially admin functions and APIs

Implement complete server-side authentication checks (Primary Defense)

  • Validate credentials or tokens on the server: Verify passwords, API keys, session IDs, JWT signatures, issuer/audience, expiration, and revocation status as appropriate for the mechanism.
  • Bind identity to a server-validated principal: Do not trust client-supplied user IDs, roles, or login flags.
  • Fail closed: Missing, malformed, expired, or invalid credentials must result in 401 Unauthorized.
  • Regenerate sessions after login: Prevent session fixation by issuing a fresh session identifier after successful authentication.
  • Protect all authenticated entry points: Apply authentication middleware/guards consistently to APIs, admin interfaces, and file endpoints.

Add multi-factor authentication for higher assurance

  • Use multiple independent factors to verify identity:
    1. Something you know (password, PIN)
    2. Something you have (hardware token, phone, authenticator app)
    3. Something you are (biometric: fingerprint, face recognition)
  • Require MFA for administrative and sensitive accounts: Mandatory for privileged access
  • Offer MFA for all user accounts: Recommended for all users
  • Use standards: TOTP (RFC 6238), WebAuthn, FIDO2
  • Support app-based authenticators: Google Authenticator, Authy, Microsoft Authenticator
  • Provide backup codes for account recovery: Enable users to regain access if device lost
  • Treat SMS/voice as restricted or lower assurance: Prefer phishing-resistant authenticators such as WebAuthn/FIDO2 where possible; SMS is vulnerable to SIM swapping and number reassignment.
  • Why this works: MFA reduces the chance that password compromise alone leads to account compromise. It strengthens authentication but does not replace server-side credential/session validation and can still be bypassed by phishing or weak recovery flows.

Use proven authentication frameworks (Defense in Depth)

  • Don't build authentication from scratch: Use established, secure frameworks
  • Modern frameworks provide:
    • Secure password hashing (bcrypt, Argon2)
    • Session management with secure defaults
    • CSRF protection
    • Rate limiting
    • Account lockout mechanisms
  • Recommended options:
    • Java: Spring Security, Apache Shiro, Keycloak
    • .NET: ASP.NET Core Identity, OpenIddict, Duende IdentityServer
    • Python: Django auth, Flask-Security, Authlib
    • Node.js: Passport.js, Auth0, Auth.js/NextAuth
    • Standards: OAuth 2.0, OpenID Connect providers

Enforce authentication on all protected resources

  • Default to "deny all": Require explicit authentication grants
  • Check at application layer: Don't rely solely on web server authentication
  • Verify every request: Don't assume session validity
  • Protect all endpoints: API endpoints, admin interfaces, file access
  • Hand off to authorization: After authentication, use authorization controls such as RBAC/ABAC to decide what the authenticated principal may access.
  • Review indirect access: Direct object references, file paths

Implement account security controls

  • Rate limiting:
    • Limit failed login attempts (e.g., 5 attempts per 15 minutes)
    • Implement progressive delays after failed attempts
    • Use CAPTCHA or other risk-based challenges after multiple failures where appropriate, considering accessibility and usability
    • Monitor for distributed brute force attacks
  • Account lockout:
    • Temporary lockout or progressive throttling after repeated failures
    • Avoid permanent or easily-triggered lockouts that let attackers deny service to users
    • Require account recovery process or admin unlock only for high-risk cases
    • Alert users to suspicious login attempts
  • Monitoring:
    • Log all authentication events (success and failure)
    • Alert on unusual patterns (impossible travel, new devices)
    • Track failed attempts by IP and username

Test authentication controls thoroughly

  • Test authentication bypass attempts: Missing credentials, empty passwords, SQL injection in login
  • Test session management: Session fixation, session hijacking, concurrent sessions
  • Test account lockout: Verify lockout after failed attempts
  • Test MFA: Attempt bypass, test backup codes, verify enforcement
  • Test password reset: Ensure secure token generation and validation
  • Verify all protected resources require authentication
  • Use automated scanners and penetration testing
  • Re-scan with security scanner to confirm the issue is resolved

Access Control Testing

Test scenarios:

  • Access protected browser page without authentication → Should redirect to login; API requests should return 401 Unauthorized
  • Access protected resource with invalid token → Should return 401 Unauthorized
  • Access admin function as regular user → Should return 403 Forbidden from authorization controls
  • Logout and attempt to reuse session token → Should require re-authentication

Brute Force Protection Testing

# Attempt multiple failed logins

for i in {1..10}; do
  curl -X POST https://app.com/login \

    -d "username=admin&password=wrong$i"

done

Expected result: After threshold (e.g., 5 attempts), receive rate limit error or account lockout.

MFA Verification Testing

  • Attempt login with valid password but no MFA code → Should require MFA
  • Attempt login with valid password and invalid MFA code → Should reject
  • Attempt to reuse MFA code → Should reject (prevent replay attacks)
  • Verify backup codes work when primary MFA unavailable

Session Security Testing

  • Verify session tokens are cryptographically random
  • Check session cookies have Secure, HttpOnly, SameSite attributes
  • Test session timeout (idle sessions should expire)
  • Verify concurrent session limits work (if implemented)

Authentication Bypass Testing

Common bypass attempts:

  • Remove authentication headers
  • Use different HTTP methods (POST vs GET)
  • Add parameters like debug=true, admin=1
  • Access resources via direct URL/path manipulation
  • Test API endpoints separately from UI

Additional Resources