Broken Authentication

How the attack works

The API verifies a user's identity incorrectly or insufficiently. Per OWASP, there are several typical causes.

• Credential stuffing and brute force: the API allows trying leaked username/password lists (credential stuffing) or brute-forcing a single account without a captcha or account lockout.
• Weak passwords: it accepts weak passwords.
• Sensitive data in the URL: it sends sensitive data such as auth tokens or passwords in the URL.
• Missing password confirmation: it allows sensitive operations (changing email address or password) without re-confirming the password.
• Flawed token validation: it doesn't correctly validate the authenticity of tokens, accepts unsigned or weakly signed JWTs ({"alg":"none"}), or doesn't check the JWT expiration date.
• Weak password protection: it uses plaintext, unencrypted, or weakly hashed passwords and weak encryption keys.

With microservices, the API is additionally vulnerable if other microservices can be accessed without authentication or if weak or predictable tokens are used for authentication.

The attacker exploits these gaps to obtain valid tokens or to bypass existing protections (e.g. rate limiting).

Example

OWASP scenario 1 (bypassing rate limiting via GraphQL batching): the login endpoint allows only 3 requests per minute, meant as a brute-force protection.

1. Normal login request: POST /graphql with { "query":"mutation { login(username:\"\", password:\"\") { token } }" }
2. The attacker bypasses the limit by bundling many login attempts into ONE request (GraphQL query batching). Because the API only counts requests, not the individual mutations they contain, the attacker can try many passwords against the victim's account per allowed request: POST /graphql with an array of multiple login mutations for victim with different passwords (password, 123456, qwerty, ..., 123).
3. As soon as one password matches, the valid token is returned and the attacker has taken over the account.

OWASP also lists a scenario 2: a PUT /account changes the account email without re-confirming the password; an attacker with a stolen auth token can thereby take over the account by changing the email and then triggering a password reset.

Impact

Per OWASP, attackers can gain full control over other users' accounts in the system. They can read the victims' personal data and perform sensitive actions in their name.

Especially critical: the systems generally can't distinguish the attacker's actions from those of a legitimate user.

In business terms, this means account takeover, data breaches, and fraud committed in the name of real customers.

How to protect against it

• Know all possible authentication flows (mobile, web, deep links, one-click logins, etc.) and explicitly ask your own developers about forgotten flows.
• Truly understand authentication mechanisms, OAuth is NOT authentication, and neither are API keys.
• Don't reinvent authentication, token generation, or password storage; use established standards instead.
• Protect password recovery/'forgot password' endpoints exactly like login endpoints (brute-force protection, rate limiting, lockout).
• Require re-authentication for sensitive operations (e.g. changing the account email or the 2FA phone number).
• Apply the OWASP Authentication Cheat Sheet.
• Implement multi-factor authentication (MFA) where possible.
• Use anti-brute-force mechanisms against credential stuffing, dictionary, and brute-force attacks, stricter than normal rate limiting.
• Implement account lockout or captcha mechanisms against attacks on individual users, along with checks for weak passwords.
• Don't use API keys for user authentication, only for authenticating API clients.

Sources

• API2:2023 Broken Authentication - OWASP API Security Top 10 2023 OWASP, 2023