APIs now carry the majority of web traffic, and attackers have followed. Because APIs expose business logic and data directly — often with thinner UI-layer protections — they fail in their own characteristic ways. The OWASP API Security Top 10 captures these, and this guide walks the risks that matter most.
Why APIs need their own Top 10
A traditional web app mixes presentation and logic; an API is pure logic and data. That means the classic weak point is authorisation, applied per-object and per-function across hundreds of endpoints. Get one wrong and an attacker reads or changes data directly. APIs also tend to over-share, trusting clients to filter — a mistake attackers exploit constantly.
The risks that matter most
- BOLA (Broken Object Level Authorization): the API returns any object whose ID you supply, regardless of ownership — the API form of IDOR and the #1 API risk.
- Broken authentication: weak token validation, long-lived tokens, and endpoints that forget to require auth at all.
- BFLA (Broken Function Level Authorization): a normal user calls an admin-only method directly because the check lives only in the UI.
- Excessive data exposure: the endpoint returns full objects and relies on the client to hide fields — so the attacker just reads the raw response.
- Mass assignment: the API binds request fields to internal properties, letting an attacker set
role=adminorisVerified=true. - Lack of rate limiting: enabling credential stuffing, scraping and resource exhaustion.
A concrete example
A mobile app calls GET /api/users/1041/cards. Change 1041 to another user’s ID and the API returns their saved cards — BOLA in one request. Or PATCH /api/users/1041 with {"role":"admin"} in the body succeeds because the endpoint mass-assigns unchecked fields. Neither needs sophistication; both are catastrophic.
How to secure your APIs
- Enforce object-level authorisation on every endpoint — verify the caller owns the object, every time.
- Apply function-level checks server-side, never relying on the client to hide capabilities.
- Return only the fields the client needs; never trust the client to filter.
- Explicitly allowlist which properties can be set, defeating mass assignment.
- Rate-limit and monitor; validate tokens strictly and keep them short-lived.
- Maintain an accurate inventory — “shadow” and deprecated endpoints are a favourite entry point.
How we test for it
We enumerate every endpoint (documented and undocumented), then test object- and function-level authorisation with multiple accounts, probe for mass assignment and excessive data exposure, and check rate limiting and token handling. This is the substance of API penetration testing, and it pairs closely with GraphQL security testing for graph APIs and with broken access control testing for the authorisation core.
Frequently asked questions
We use OAuth — are we covered? OAuth handles authentication, not per-object authorisation. BOLA happens regardless of how you log users in.
Does GraphQL change the risks? The categories are similar but introspection and nested queries add attack surface — see GraphQL security testing.
Want every endpoint tested for BOLA and mass assignment? Explore API penetration testing or get a fixed-price quote.