API Security Risks

API vulnerabilities look different from classic web ones. There is less injection and far more authorisation — because an API exposes objects and operations directly, and each one has to independently decide whether this caller may touch it.

Broken object level authorisation (BOLA) is the most common and most damaging. GET /orders/1234 authenticates the caller, then returns order 1234 without checking they own it. Changing the id walks the whole table. Also known as IDOR. Unguessable ids are not a fix — that is obscurity, not authorisation. Every object access needs an ownership check at the point of access.

Broken function level authorisation is the same failure applied to operations: an admin endpoint that is merely undocumented rather than actually protected.

Broken object property level authorisation covers two familiar bugs. Excessive data exposure is returning the whole record and letting the client hide fields — the data is in the response whatever the UI does. Mass assignment is binding request JSON straight onto a model, so a caller who adds "role": "admin" gets exactly that. Bind to an explicit allowlist of fields.

Unrestricted resource consumption is missing rate limits, unbounded page sizes, and queries a caller can make arbitrarily expensive.

Server-side request forgery appears anywhere your API fetches a URL the caller supplied.

Improper inventory management is the quiet one: forgotten /v1 endpoints still running unpatched next to /v3, staging hosts exposed to the internet, undocumented internal APIs. You cannot secure what nobody remembers exists, which is why an inventory is a security control.

Unsafe consumption of APIs — trusting a third-party response because it came from a partner. Validate what comes back as carefully as what comes in.