REST API Security
APIs are the backbone of modern applications — and because every endpoint is directly callable, with no UI to hide behind, they are a major attack surface. REST API security is mostly the disciplined application of familiar principles to endpoints that machines call directly: prove identity, check authorization on every object, validate everything, and limit abuse.
What are the core controls?#
| Control | What it prevents |
|---|---|
| Strong authentication | Unauthenticated access, weak tokens |
| Object-level authorization | IDOR — reaching others’ data |
| Input validation | Injection, malformed data |
| Output minimization | Excessive data exposure |
| Rate limiting | Brute force, abuse |
| Field allowlisting | Mass assignment |
The dominant risk, per the OWASP API Security Top 10, is broken object-level authorization — the API returns record 124 to a user who owns only record 123, because it checked login but not ownership. Every endpoint must verify access to the specific object requested.
Why do APIs need extra care?#
Because a browser flow has implicit constraints an API does not. There is no rendered page to limit what a client does; the client may be a script sending any request in any order. So assumptions like “the UI never shows this button to normal users” mean nothing — the endpoint is callable regardless, and must enforce the rule itself.
REST API security applies web fundamentals to machine-facing endpoints. See also GraphQL security and the Web Security hub.
Frequently asked questions#
What are the biggest REST API security risks?
Broken object-level authorization (accessing other users’ records), broken authentication, excessive data exposure (returning more than the client needs), lack of rate limiting, and mass assignment. The OWASP API Security Top 10 captures these — most are authorization failures, the same theme as broken access control on the web.
How is API security different from web page security?
APIs have no UI to hide behind — every endpoint is directly callable, and clients are often other machines. There is no server-rendered page to constrain behavior, so each endpoint must independently authenticate, authorize, and validate. Assumptions that hold for a browser flow do not hold for a raw API client.