Broken Authentication in APIs | OWASP API2:2023 Explained
A Guide to Broken Authentication
Broken authentication occurs when authentication mechanisms are implemented incorrectly, letting attackers compromise tokens or exploit implementation flaws to assume another user’s identity, temporarily or permanently.
Authentication is the foundation every other API control depends on. When an attacker impersonates a legitimate user, downstream authorization checks become meaningless, because the system believes the attacker is who they claim to be.
The flaws that create this risk are rarely exotic: skipped rate limiting, weak token validation, credentials handled carelessly.
Key Takeaways
- Broken authentication is ranked #2 in the OWASP API Security Top 10 2023 and can allow attackers to gain complete control of other users’ accounts and perform actions on their behalf
- APIs are vulnerable when they allow brute force or credential stuffing attacks without rate limiting, account lockout, or CAPTCHA mechanisms in place
- Common implementation flaws include accepting unsigned or weakly signed JWT tokens, not validating token expiration, sending auth tokens in URLs, and using weak or plain-text password storage
- GraphQL query batching is a specific attack vector that can be used to bypass per-request rate limiting, enabling high-speed brute force attacks against authentication endpoints
- Prevention requires enforcing multi-factor authentication, re-authentication for sensitive operations, strict anti-brute force controls, and following established standards rather than building custom auth mechanisms
Why is it Dangerous
Flawed authentication mechanisms give an intruder complete control of another user’s account. Consequences include:
- Full account takeover and impersonation
- Bypass of every downstream authorization control tied to that identity
- Exposure of any data or function the compromised account reaches
- No way to distinguish the attacker’s actions from the legitimate user’s, since the system trusts the compromised identity completely
- A takeover of an administrative account that cascades across the entire system
Typical Manifestations
Broken authentication commonly appears when APIs:
- Permit credential stuffing, allowing brute force with lists of valid username and password pairs
- Allow repeated login attempts on a single account without CAPTCHA or lockout
- Send auth tokens or passwords as part of a URL, where they end up in logs and browser history
- Accept unsigned or weakly signed JWTs, including tokens using {“alg”:”none”}
- Fail to validate JWT expiration
- Allow GraphQL query batching to bundle many log-in attempts into one request, sidestepping per-request rate limits
- Let a user change their email or password without confirming their current password first, opening a path to account takeover
When one or more of these conditions exist, the system cannot reliably confirm the identity behind the request.
Prevention Principles
Authentication has to confirm a user’s identity accurately, or every downstream control built on top of it fails.
- Map every flow that authenticates to the API, including mobile, web, and one-click deep links, so none are overlooked
- Understand your authentication mechanisms fully; OAuth is not authentication, and neither are API keys
- Don’t reinvent the wheel in authentication, token generation, or password storage; use established standards
- Treat credential recovery and forgot-password endpoints with the same protections as login endpoints
- Require re-authentication before sensitive changes, such as updating an email address or 2FA phone number
- Implement multi-factor authentication wherever possible
- Implement anti-brute-force mechanisms, such as stricter than standard API rate limiting, to mitigate credential stuffing and dictionary attacks
- Implement account lockout and CAPTCHA protections against targeted brute force, along with weak-password checks
- Reserve API keys for authenticating API clients, never for authenticating individual users
Don’t reinvent authentication. The standards exist because the failure modes are well understood. Building custom systems around them reintroduces the same flaws.
