Skip to content

Application security

API security starts with authorization, not the gateway

The most damaging API bugs need no exploit, just a valid token and someone else's object ID. Fix authorization first.

Resilient Privacy Research · · 2 min read

Simulated environment, real workflow.

The common failure is logic, not syntax

Serious API incidents rarely need an exotic exploit. They need a valid session and a different identifier in the URL. A gateway, a WAF and TLS all see a well-formed request from a logged-in user, and let it through. That is why the OWASP API Security Top 10 (2023) puts Broken Object Level Authorization first.

The OWASP API Security Top 10, in plain terms

  • Broken object level authorization: a user can read or change objects that belong to someone else by changing an ID.
  • Broken authentication: weak token handling, missing expiry, or login flows that allow credential stuffing.
  • Broken object property level authorization: the API returns or accepts fields the caller should not see or set.
  • Unrestricted resource consumption: no limits on request size, rate or cost.
  • Broken function level authorization: ordinary users can call admin functions.
  • Unrestricted access to sensitive business flows: automation abuse of flows like sign-up, checkout or booking.
  • Server-side request forgery: the API fetches a URL the attacker supplies.
  • Security misconfiguration: verbose errors, permissive CORS, missing hardening.
  • Improper inventory management: old versions and forgotten hosts still answering.
  • Unsafe consumption of APIs: trusting data from third-party APIs without validation.

Inventory before protection

You cannot protect endpoints you don't know about: old versions, staging hosts exposed to the internet, partner integrations and endpoints added by one team in a hurry. Build the inventory from three sources and compare them: API specifications, gateway and load balancer logs, and live traffic. Endpoints in traffic but missing from the spec are shadow APIs. Deprecated versions that still answer are zombie APIs. Both should be owned or removed.

Controls that work

  • Central authorization: check object ownership on every request in a shared library or policy layer, never from client-supplied data alone.
  • Explicit response schemas: return only the fields the caller may see, instead of serializing whole objects.
  • Business-aware rate limits: limit by user, token and action, not just by IP address.
  • Schema validation at the edge: reject requests that don't match the OpenAPI definition.
  • Short-lived, audience-restricted tokens, revoked on logout and password change.
  • Outbound allowlists: stop SSRF by limiting where the API may fetch from.
  • Untrusted upstreams: validate responses from third-party APIs like any other input.

Test the logic

Scanners find missing headers. They rarely find broken object level authorization, because they don't know which user owns which object. Write authorization tests with two users per role and assert that cross-access fails, then run them in CI on every change. Pair that with periodic manual testing focused on business flows.

Want a second pair of eyes on this?

Talk to the practitioners behind our research about your environment.