API security: why authorisation flaws beat every scanner

The dominant class of API vulnerability is not injection or misconfiguration - it is authorisation. The request is well-formed, authenticated, and entirely legitimate looking. It simply asks for someone else's data, and the API answers. Scanners struggle with this because nothing about the request is malformed; only the business context makes it wrong.

The authorisation failures that matter

• Broken object level authorisation - changing an identifier in the request path or body returns another tenant's or user's record. The single most common serious API flaw.
• Broken function level authorisation - a standard user reaching an administrative endpoint because the check lives in the UI rather than the API.
• Broken object property level authorisation - the endpoint returns fields the caller should not see, or accepts fields they should not be able to set.
• Excessive data exposure - returning the full object and relying on the client to display a subset, which anyone can bypass by reading the response.

The common root cause is authorising at the endpoint but not at the object. "Is this user allowed to call this endpoint?" is not the same question as "is this user allowed to see this record?" - and only the second one protects tenant data.

Shadow and zombie APIs

You cannot protect endpoints you do not know exist:

• Shadow APIs - deployed without going through review or documentation.
• Zombie APIs - old versions still running after clients migrated, usually unpatched and unmonitored.
• Undocumented internal APIs that turn out to be reachable from outside.

Discovery beats guesswork: derive an inventory from gateway and load balancer traffic, not only from your specification files. The gap between the two is the finding.

Controls that work

1. Authorise at the object level, server-side, every time. Enforce it centrally rather than trusting each endpoint author to remember.
2. Maintain an API inventory derived from live traffic, with an owner and a documented lifecycle per endpoint.
3. Version and retire deliberately - a published deprecation policy prevents zombies.
4. Rate limit and quota per client, which blunts enumeration and scraping even where authorisation is sound.
5. Validate against a schema and reject unexpected fields rather than silently binding them.
6. Return only what is needed - filter server-side, never in the client.
7. Log with the caller identity and object accessed, which is what makes investigation and access-to-data evidence possible.
8. Test authorisation explicitly - automated tests that attempt cross-tenant access on every endpoint, run in CI.

That last one is the highest-value engineering practice here. Authorisation bugs are reintroduced constantly by ordinary feature work, and only a test suite catches them repeatedly.

Where APIs meet compliance

• Access to sensitive data - frameworks require logging who accessed what. For API-delivered data, that logging has to be at the API layer.
• Authentication requirements - MFA expectations apply to human-facing APIs; machine clients need strong credential management instead.
• Penetration testing - scope must include APIs explicitly and with authenticated credentials, or the test misses the dominant flaw class.
• Privacy - an API returning more personal data than necessary is a data minimisation issue as well as a security one.
• Third-party integration - partner API access belongs in your vendor and access review scope.

Key takeaways

• Authorisation flaws dominate, and scanners rarely find them.
• Authorise per object, server-side, enforced centrally.
• Build the API inventory from live traffic, not from documentation.
• Automate cross-tenant authorisation tests in CI - they regress constantly.