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
  • Privilege escalation: Gain administrative or elevated access rights
  • 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 authorization
  • 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 parameter manipulation: Changing isAdmin=false to isAdmin=true, modifying user IDs in requests
  • 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 strong multi-factor authentication (Primary Defense)

  • 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
  • Avoid SMS as sole second factor: Vulnerable to SIM swapping attacks
  • Why this works: Even if passwords are compromised, attackers cannot authenticate without the second factor

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 Identity, IdentityServer
    • Python: Django auth, Flask-Security, Authlib
    • Node.js: Passport.js, Auth0, 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
  • Implement RBAC: Role-based access control after authentication
  • 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 after multiple failures
    • Monitor for distributed brute force attacks
  • Account lockout:
    • Temporary lockout after repeated failures
    • Require account recovery process or admin unlock
    • 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 resource without authentication → Should redirect to login
  • Access protected resource with invalid token → Should return 401 Unauthorized
  • Access admin function as regular user → Should return 403 Forbidden
  • 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

Dynamic Scan Guidance

For guidance on remediating this CWE when detected by dynamic (DAST) scanners:

Additional Resources