API security is the practice of protecting an API from unauthorized access, data exposure, and abuse across its whole surface: authentication, authorization, input handling, and the data it returns. APIs are now the primary way applications talk to each other, which also makes them the primary target; most modern breaches happen through an API, not a web page.
What API Security Covers#
Securing an API means defending several distinct layers, not just adding a login:
- Authentication: proving who is calling (tokens, API keys, OAuth)
- Authorization: deciding what that caller is allowed to do, per request and per object
- Input validation: rejecting malformed, oversized, or malicious payloads
- Rate limiting and abuse control: stopping one client from overwhelming or scraping the API
- Data exposure: returning only the fields a client needs, never the whole record
- Transport: encrypting everything in transit with TLS
A weakness in any one of these is enough; an authenticated user who can read another user's data is just as breached as one who never logged in.
The OWASP API Security Top 10#
The OWASP API Security Top 10 is the standard reference for the most common API risks. The recurring themes:
| Risk | What it means |
|---|---|
| Broken object-level authorization (BOLA) | A caller reads or edits a record that is not theirs by changing an ID |
| Broken authentication | Weak or missing token checks let attackers impersonate users |
| Broken property-level authorization | The API returns or accepts fields the caller should not see or set |
| Unrestricted resource consumption | No rate limits, so the API can be flooded or run up costs |
| Security misconfiguration | Default settings, verbose errors, or open CORS leak information |
BOLA is consistently the number one API breach: the endpoint authenticates the user but never checks that this user owns the record they asked for.
API Security vs Application Security#
Application security covers the whole app, including the UI, sessions, and server. API security is the subset focused on the machine-to-machine interface, where there is no browser to enforce rules and every request is forgeable. The risks overlap, but APIs shift the weight toward authorization and data exposure because the client is untrusted by definition.
Best Practices#
- Authenticate and authorize on every request. Treat each call as hostile; never trust a prior step.
- Check ownership, not just identity. Confirm the caller owns the specific object, which closes the BOLA gap.
- Validate input and rate-limit. Reject bad payloads early and cap how often a client can call.
- Return the minimum. Send only the fields the client needs, so a leak exposes less.
- Test continuously. Pair a penetration test for depth with automated checks that catch regressions between tests.
Limitations to Know#
- Tools find known patterns. Scanners catch common misconfigurations, but business-logic flaws (who should access what) still need human review.
- Security is not a one-time task. Every new endpoint is new surface; a clean audit last quarter says nothing about the route you shipped yesterday.
- Auth is necessary, not sufficient. Most API breaches happen to authenticated callers, so logging in is the start of the problem, not the end of it.
Conclusion#
API security is about defending the whole request path: who is calling, what they are allowed to touch, what they send, and what comes back. The single biggest win is per-object authorization, since the most common breach is an authenticated user reaching data that is not theirs.
One thing that quietly erodes API security is regression: an auth check that worked last release silently breaks after a refactor. ObserveOne's API checks can run continuously against your endpoints and assert the expected behavior, for example that an unauthenticated request still returns 401 and not 200, so a broken auth control surfaces as a failed check instead of a breach.