Events & community · Information security · 3 min read
API Security Today: The OWASP API Top 10 in Practice
Short answer
Most API breaches come from authorization mistakes rather than broken cryptography: the OWASP API Security Top 10 (2023) is led by broken object level authorization, broken authentication and broken object property level authorization, so every endpoint must check that this caller may act on this specific object and field.
Key takeaways
- Validating a token proves who the caller is; it does not prove they may read object 4711.
- Rate limits, pagination caps and payload limits belong in the design, not only in the gateway.
- Keep an inventory of every API version and host; forgotten endpoints are a top-ten risk on their own.
Talks about API security at internet conferences tend to cover the same ground year after year, because the same mistakes keep happening. The OWASP API Security Top 10 captures them well. This piece runs through the 2023 edition the way a conference talk might: what each risk looks like, and the fix that actually works.
Why do APIs get breached?
Usually because an endpoint trusted a valid token to mean a valid request.
APIs expose business objects directly: accounts, orders, records. Authentication answers "who is calling". Authorization has to answer "may this caller do this, to this object, with these fields", and that check is easy to forget on one endpoint out of two hundred.
What are the top risks, and what fixes them?
Here is the 2023 list with the core fix for each.
| # | Risk | What it looks like | Core fix |
|---|---|---|---|
| API1 | Broken object level authorization | Change /accounts/4711 to /accounts/4712 and see someone else's data |
Check ownership or policy for every object on every request |
| API2 | Broken authentication | Weak tokens, no expiry check, credential stuffing on login | Standard OAuth/OIDC, validate iss/aud/exp/signature, rate-limit login |
| API3 | Broken object property level authorization | API returns or accepts fields the caller should not see or set | Explicit response schemas; allowlist writable fields |
| API4 | Unrestricted resource consumption | Huge page sizes, expensive queries, no limits | Limits on rate, page size, payload, execution time |
| API5 | Broken function level authorization | Regular user calls an admin endpoint | Deny by default; role checks per function |
| API6 | Unrestricted access to sensitive business flows | Bots buy all the tickets or create mass accounts | Flow-specific protections, device and behavior signals |
| API7 | Server-side request forgery | API fetches a URL the caller supplied | Allowlist destinations; block internal ranges |
| API8 | Security misconfiguration | Verbose errors, open CORS, missing TLS settings | Hardened defaults, review, headers |
| API9 | Improper inventory management | Old v1 still live, test hosts exposed | Inventory every host and version; retire old ones |
| API10 | Unsafe consumption of APIs | Trusting data from third-party APIs blindly | Validate and limit what you receive |
How should an API validate tokens?
Verify the signature with a pinned algorithm and trusted keys, then check issuer, audience, expiry and scope, before any business logic.
RFC 8725 (JWT best current practices) is short and worth reading. In particular: never accept alg: none, do not let the token choose the algorithm, check aud so a token for another API is rejected, and keep clock skew small. Paste a sample token from your system into the JWT Decoder and see what warnings appear.
Where does object-level authorization live?
In the service, or a policy engine the service calls, because only the service knows who owns object 4712.
A gateway can confirm a token has orders:read. It cannot know that order 4712 belongs to a different customer. Write the check once in a shared helper or middleware, call it from every handler, and add tests that try to access another user's objects. Policy engines with ABAC models help when rules get complex; see the authorization guide.
Where can I go deeper?
The OWASP project pages, API security talks at identity and developer conferences, and local meetups.
Our pages on API gateways and API security events and communities are good next steps.
Questions
What changed in the 2023 edition of the OWASP API Top 10?
The 2023 edition merged excessive data exposure and mass assignment into broken object property level authorization, and added unrestricted access to sensitive business flows, server-side request forgery and unsafe consumption of APIs, among other changes.
Does an API gateway solve these problems?
A gateway helps with authentication, rate limiting, schema validation and inventory. Object-level and property-level authorization depend on business data, so they must be enforced in the service or a policy engine it calls.
Sources
Tagged: Nordic API community, API, APIs and the API economy, Event, OAuth, Security, REST