OWASP Top 10:2021 — A07: Identification and Authentication Failures
Welcome back to this deep dive into the OWASP Top 10. Today we’re looking at something fundamental: authentication.
Your app can have perfect logic, great encryption, and secure infrastructure — but if anyone can impersonate a legitimate user, none of it matters.
This OWASP category focuses on weaknesses in how users are identified, authenticated, and managed. It’s all about the front door — and how attackers break in when it’s not properly locked.
Full series:
- A01: Broken Access Control
- A02: Cryptographic Failures
- A03: Injection Attacks
- A04: Insecure Design
- A05: Security Misconfiguration
- A06: Vulnerable and Outdated Components
- A07: Identification and Authentication Failures (you are here)
- A08: Software and Data Integrity Failures
- A09: Security Logging and Monitoring Failures
- A10: Server-Side Request Forgery (SSRF)
What Is an Identification and Authentication Failure?
This category includes:
- Broken or missing authentication logic
- Predictable or weak credentials
- Brute-force vulnerabilities
- Poor session handling
- Misuse of authentication protocols
The goal of authentication is simple: prove someone is who they claim to be. When that fails, attackers can:
- Log in as another user
- Elevate privileges (e.g., from user to admin)
- Hijack sessions or tokens
- Bypass login flows entirely
Common Vulnerabilities
- Weak Password Policies
Short, simple passwords (e.g., password123) still work — because many systems still allow them.
- No Rate Limiting on Login
An attacker can try thousands of credentials using a brute-force or credential stuffing attack.
- Session Fixation or Hijacking
If session IDs are predictable or reused across logins, attackers can hijack valid sessions.
- Improper MFA Implementation
Implementing 2FA but only applying it to some users or actions. Or worse, allowing fallback to SMS with no lockout.
- Exposed Authentication Endpoints
APIs that return verbose error messages (“Invalid password” vs. “User not found”) can leak valid usernames.
How Attackers Exploit This
Credential Stuffing
Attackers use usernames and passwords leaked from other sites to log in to yours — because people reuse passwords all the time.
Business Logic Failures
Some flows allow password resets or email changes without reauthentication. Others might let users stay logged in after a password change.
JWT Abuse
Improperly signed or weakly protected JSON Web Tokens (JWTs) can be manipulated, especially if the algorithm is set to none or uses a public key for verification.
How Engineers Can Defend Against This
Authentication is high-risk. Treat it accordingly. Here’s how:
- Enforce Strong Passwords
- Minimum length (e.g. 12+)
- Check against known breached passwords (use services like HaveIBeenPwned)
- Consider passphrases over complex symbols
- Enable MFA Everywhere
- Don’t make it optional for sensitive roles
- Prefer app-based MFA (TOTP) over SMS
- Secure the recovery flows (MFA backup codes, secure reset processes)
- Use Rate Limiting and Lockout
- Throttle failed logins
- Lock accounts temporarily after X failed attempts
- Use CAPTCHAs for public-facing forms
- Secure Sessions
- Regenerate session IDs after login
- Expire sessions on logout and after inactivity
- Store session tokens securely with HttpOnly, Secure, and SameSite flags
- Don’t Build Your Own Auth
- Use hardened identity providers (e.g., Auth0, Okta, Firebase Auth)
- If you must implement your own, follow OWASP’s Authentication Cheat Sheet
Real-World Case: Broken Auth, Broken Business
An ecommerce platform implemented a password reset flow that allowed users to reset a password without verifying the reset token’s expiration.
An attacker found a way to reuse old reset links from inboxes of compromised email accounts — gaining full control of customer profiles and payment methods.
It wasn’t a code bug — just an incomplete authentication flow.
Final Thoughts
Authentication isn’t just a login screen. It’s an entire lifecycle:
- Registration
- Login
- Session management
- Logout
- Password reset
- MFA and recovery
Each part is a chance to get security right — or dangerously wrong.
Next up: A08: Software and Data Integrity Failures → We’ll look at how unsigned updates, insecure pipelines, and tampered packages can undermine everything your users trust.
Leave a comment