API security is more than authentication

“Our API requires authentication” is often treated as equivalent to “our API is secure.” It isn’t. Authentication answers one question — who is making this request — and leaves several other, frequently more exploitable questions unanswered.

Authorization is the bigger gap

Broken object-level authorization — where an authenticated user can access or modify data belonging to someone else simply by changing an ID in the request — is one of the most common and most damaging API vulnerabilities in practice. The request is perfectly authenticated; it’s authorized incorrectly, because the API never checks whether the caller actually owns the resource they’re asking for.

This is a design and implementation problem, not something a login screen or API key can prevent. It has to be checked on every endpoint that touches user-specific data, not assumed to be handled globally.

Excessive data exposure

APIs frequently return more data than the calling application actually needs, relying on the frontend to filter what’s displayed. That’s fine until someone calls the API directly instead of through the intended frontend, at which point the full, unfiltered response — including fields never meant to be exposed — becomes visible.

Rate limiting and abuse

Without meaningful rate limiting, an authenticated API can still be abused: scraped at scale, used to enumerate valid accounts or IDs, or hit hard enough to affect availability for other users. Authentication doesn’t prevent abuse from a legitimately authenticated but malicious or compromised caller.

Undocumented and forgotten endpoints

APIs accumulate endpoints over time — internal tools, deprecated versions, admin functions — that were never intended for broad access and often never got the same security review as the main product surface. These “shadow” endpoints are a common finding simply because nobody remembered to include them in scope.

The practical takeaway

A meaningful API security review has to go past “does this endpoint require a valid token” and ask, for every endpoint: what can an authenticated-but-unauthorized caller actually do here, and what does this endpoint return that it shouldn’t.

API security reviews are built specifically around these failure modes, usually alongside a broader application security review of the surrounding codebase.