DEV Community

StarkMan
StarkMan

Posted on

API Authentication Failures: Checks to Run Before You Blame the Rate Limiter

#apisecurity #authorization #owasp #ratelimiting

API Authentication Failures: Checks to Run Before You Blame the Rate Limiter

Broken object-level authorization, missing authentication on internal endpoints and unlimited credential guessing appear repeatedly in the OWASP API Security Top 10. The failures share a structure: the endpoint exists, the documentation describes it, and no control sits in front of it.

Authentication versus authorization

An endpoint that verifies a token is authenticated. An endpoint that verifies the token belongs to a subject allowed to act on the specific object is authorized. Object-level authorization is the check most often missing, because it requires knowing which object was requested and who owns it.
The defensive pattern is to resolve the subject from the token and then query with the subject as a filter, rather than fetching the object and comparing afterwards.

Mass assignment

If the request body is bound directly to an internal model, a client can set fields the interface never intended to expose, including roles, account flags and ownership. An explicit allowlist of writable fields is the only reliable control.

Credential stuffing and rate limits

Rate limiting reduces the throughput of credential guessing. It does nothing about a valid credential that was phished, so it cannot substitute for authentication. Pair it with monitoring of failed authentication per account and per source, and with a lockout or step-up policy that applies to the account rather than only to the source address.

The inventory problem

Internal endpoints and older API versions frequently skip the controls applied to the public interface. Inventorying the deployed routes and comparing them against the documented ones is how those endpoints are found.

References

Top comments (0)