Broken Authentication: When the API Front Door Doesn't Lock

Authentication is the claim an API makes about who is on the other end of the connection. Get it wrong and every other control downstream is meaningless — authorization checks, rate limits, audit logs all rest on an identity the attacker has already forged. OWASP ranks Broken Authentication second among API risks because the mistakes are common, the mechanisms are complex, and a single flaw hands over accounts wholesale.

The category is broad by design. It covers any weakness that lets an attacker assume another user's identity: credential stuffing that meets no rate limit, tokens that never expire or are signed with a guessable secret, a password-reset flow that leaks or accepts predictable codes, or an endpoint that accepts an unsigned JWT because the server trusts the alg header the client sent. What unites them is that the API believes a lie about who is calling.

Where authentication breaks

APIs authenticate differently from the web apps that preceded them. There are no sessions tied to a browser, no server-rendered login page — just tokens, keys, and machine-to-machine flows that developers frequently roll themselves. That is where the cracks appear. The login endpoint is exposed to automation and often lacks the brute-force protection a human-facing form would have. Token handling invites subtle errors: accepting the none algorithm, failing to verify the signature, or embedding no expiry.

Account-recovery flows are a favourite target because they are, by definition, a way to gain access without the password. A reset code that is short, numeric, and unthrottled can be brute-forced; a reset link that leaks in a referer header or is guessable by timestamp is no better. And machine credentials — API keys pasted into mobile apps or committed to public repositories — turn authentication into a scavenger hunt an attacker often wins without touching your servers.

What good authentication requires

The core discipline is to treat authentication as a security-critical component that you configure rather than invent. Use vetted, standard mechanisms; assume every credential endpoint is under automated attack; and verify tokens strictly, on the server, every time.

• Rate-limit and monitor every credential endpoint. Login, token issuance, and password reset must throttle attempts and lock or challenge after repeated failures. Credential stuffing is defeated by friction, not by hope.
• Verify tokens strictly. Reject the none algorithm, pin the expected signing algorithm server-side, validate signature, issuer, audience, and expiry — and never trust claims the client can set.
• Harden account recovery. Reset codes must be long, random, single-use, and short-lived; the flow should reveal nothing about whether an account exists and must be rate-limited like login.
• Require strong authentication where it counts. Enforce multi-factor authentication for sensitive operations, and prefer short-lived tokens with refresh over long-lived bearer credentials.
• Treat API keys as secrets, not identity. Do not embed them in client-side code, rotate them, scope them narrowly, and scan repositories and mobile bundles for leaks.

Authentication is deceptively hard because it is a system, not a single check — login, tokens, refresh, recovery, and machine credentials all have to hold at once, and an attacker needs only the weakest of them. That is also why authentication flaws hide: the login page looks fine while the forgotten reset endpoint quietly accepts a four-digit code. You cannot harden the front doors you have not inventoried, which is why finding every authenticating endpoint comes before locking any of them.