API authentication attacks
When it applies
An API authenticates requests via tokens/keys/sessions. Auth is the gate; weaknesses here open everything behind it.
Why it works
APIs sprawl (many endpoints, versions, clients) so authentication is applied inconsistently: some routes forgot it, tokens are long-lived or weakly signed, keys leak client-side, and error/timing differences enable enumeration and brute force.
Method
- No-auth endpoints: replay requests with the token removed; probe
/v1vs/v2,/internal,/debug, and undocumented routes (Swagger/OpenAPI) for missing auth. - Token weaknesses: JWT issues (→
web-auth-jwt: alg confusion, weak secret, none); long/ non-expiring tokens; predictable session ids; token accepted in URL (logged/leaked). - Key leakage: hunt keys in JS bundles, mobile apps, git (→
code-review-secrets-detection), and test their privilege/scope. - Brute/enumeration: username enumeration via login/reset differences; weak rate limits on
login/OTP (→
web-race-conditionsfor OTP windows). - Auth logic: password reset token predictability/leak, 2FA bypass, "remember me" tokens.
Gotchas
- Test every version and verb — the fix may exist only on the newest route.
- A leaked key must be live and privileged to matter — validate scope, don't over-collect.
- Rate-limit "bypass" via parallelism or header rotation is reportable on many programs.
Verify success
Authenticated access without valid credentials (no-auth route, forged/replayed token, or a live leaked key performing a privileged action).
References
OWASP API Security Top 10 (API2); PortSwigger auth labs.