API security

API security differs from classic web security because an API exposes the application's object model directly: identifiers, field names and operations arrive as structured parameters that a client can enumerate and replay at machine speed, with no user interface to hide anything. The OWASP API Security Top 10 (2023) reflects this. Its first entry, API1 Broken Object Level Authorization (BOLA, the API name for IDOR), is the case where the server authenticates the caller but never checks that the object ID in the path or body belongs to them. API3 Broken Object Property Level Authorization covers both excessive data exposure (returning every column and filtering in the client) and mass assignment (binding an incoming JSON body straight onto a model so a caller can set fields such as isAdmin or ownerId). API5 Broken Function Level Authorization is the same failure one level up, for example a regular user calling an administrative DELETE endpoint.

Authentication for machine clients is usually OAuth 2.0 access tokens, often JWTs, or mutual TLS. Common failures are accepting unsigned tokens (alg none), not validating aud, iss and exp, confusing RS256 with HS256 so a public key is used as an HMAC secret, and long-lived bearer tokens with no binding to the client. Sender-constrained tokens (mTLS-bound per RFC 8705, or DPoP per RFC 9449) reduce the value of a stolen token. API keys identify a client application; on their own they do not authenticate a user.

Resource controls address API4 Unrestricted Resource Consumption and API6 Unrestricted Access to Sensitive Business Flows: rate limits per identity rather than per IP, maximum page sizes, request body limits, timeouts and, for GraphQL, query depth and cost limits plus disabled introspection in production. API9 Improper Inventory Management is the shadow and zombie API problem: old versions such as /v1 that stay reachable without the fixes applied to /v2. An OpenAPI description kept in the build pipeline gives both an inventory and a schema that a gateway can enforce.

An API gateway or WAF is good at coarse controls (TLS termination, token validation, quotas, schema checks), but it cannot know whether user 17 owns invoice 4711. Object-level authorization therefore has to live in the service, ideally in one central policy layer, and has to be tested with two accounts, since scanners that use one identity rarely find BOLA. NIST SP 800-228 frames the same controls for cloud-native, service-to-service APIs, where east-west traffic between microservices needs authentication just as much as the public edge.