Broken authentication, number two in the OWASP API Security Top 10 for 2023, means an API's login, token or password reset flows can be abused to take over accounts. The fixes are strict rate limiting on every credential path, full token validation, strong passwords and re-authentication for sensitive changes.
Why is it so common?
OWASP explains that the authentication mechanism is an easy target because it is exposed to everyone. It rates exploitability as easy and prevalence as common. Misconceptions about authentication boundaries and the complexity of implementing it make flaws widespread. The impact can be severe: attackers can gain complete control of other users' accounts, read their personal data and act on their behalf, and the system may be unable to tell them from legitimate users.
How do you know if your API is vulnerable?
OWASP's checklist says an API is vulnerable if it:
- permits credential stuffing, where lists of valid username and password pairs are tried
- permits brute force on one account without a captcha or lockout
- permits weak passwords
- sends tokens or passwords in the URL
- lets users change their email, password or other sensitive details without confirming a password
- does not validate token authenticity
- accepts unsigned or weakly signed JSON Web Tokens, including the none algorithm
- does not validate the token's expiration date
- stores passwords in plain text, encrypted instead of hashed, or weakly hashed
- uses weak encryption keys
A microservice is also vulnerable if other services can reach it without authentication, or if it uses weak or predictable tokens.
What do real scenarios look like?
OWASP gives two. In the first, a GraphQL login endpoint allows three attempts a minute. The attacker batches many login mutations into one request, so the rate limit counts one request while the server checks many passwords. The lesson: rate limit by attempts, not by HTTP requests.
In the second, an API lets a user change the account email with only a bearer token. An attacker who steals a token changes the email to their own and starts a password reset. The lesson: sensitive operations need a fresh proof of identity, such as the current password.
A constructed example
A mobile app has three ways to sign in: password, one-click email link and social login. The team hardened the password flow with lockouts and multi-factor authentication. The email link flow, built by another team, has no rate limit and issues six digit codes that never expire. An attacker ignores the hardened door and brute forces the other. OWASP's advice for this: make sure you know all the possible flows to authenticate and ask engineers what you missed. The weakest flow sets the strength of the whole system.
How do you prevent it?
OWASP's prevention guidance includes:
- List every authentication flow, including mobile, web and deep links.
- Treat password reset as seriously as login, with the same brute force and lockout protection.
- Require re-authentication for sensitive operations.
- Use standards and do not invent your own authentication, token generation or password storage. OAuth is not authentication by itself, and API keys are for identifying API clients, not users.
- Use multi-factor authentication where possible.
- Apply anti-brute-force controls on authentication endpoints that are stricter than ordinary rate limits.
- Add lockout or captcha for attacks on a single user, and check for weak passwords.
Dynamic testing finds many of these flaws by trying the flows. Safeguard's web app scan covers dynamic testing, and the demo below shows a scan.
See the full walkthrough at /demos/dast-web-app-scan.
How to check or apply this
- Draw every sign-in, token and recovery path and mark which have rate limits.
- Test batching and parallel requests against each path.
- Verify JWT signature, algorithm, expiration and audience in code, and reject unsigned tokens.
- Ask for the current password or a second factor before changing email, password or phone number.
- Hash passwords with a modern algorithm, and never log secrets or put them in URLs.
- Add automated tests for these cases to your pipeline.
Quick check
Are API keys a good way to authenticate users?
OWASP says no. API keys should only authenticate API clients, not users.
Does a rate limit on requests stop brute force?
Not if one request can carry many attempts. Limit attempts per account and per credential path.
Sources
Last reviewed: 18 October 2026.
