Abstract

API gateways are the enforcement point for authentication, rate limiting, and traffic routing in service-oriented architectures, making them a high-value target and a natural checkpoint for security controls. Applying OWASP’s API Security Top 10 as a structured threat model during gateway design and review helps teams identify gaps before they become incidents. This article walks through the most gateway-relevant risks from the 2023 OWASP API Security Top 10, maps them to concrete gateway configuration controls, and highlights where gateway enforcement has inherent limits that require defense-in-depth.

Broken Object-Level and Function-Level Authorization

OWASP API1 (Broken Object Level Authorization) and API5 (Broken Function Level Authorization) represent the two most common authorization failures in API deployments. A gateway can validate that a request carries a JWT signed by the expected issuer and that the token’s scope claim includes a required value - but it cannot, without business context, verify that the authenticated subject is authorized to access the specific resource ID embedded in the path parameter. A request to GET /accounts/87634 with a valid token may be authorized at the gateway but unauthorized at the application layer if account 87634 belongs to a different user.

This distinction is critical for threat models: gateways are the right enforcement point for coarse authorization (valid token, correct scope, permitted HTTP method), while fine-grained object-level authorization belongs in the application or a dedicated authorization service like Cerbos or OpenFGA. Threat model documentation should explicitly state what each layer checks and what it does not, so gaps are visible rather than assumed.

Unrestricted Resource Consumption and Rate Limiting Design

OWASP API4 (Unrestricted Resource Consumption) covers denial-of-service through API abuse - excessive request rates, oversized payloads, deeply nested queries. Gateways such as Kong, AWS API Gateway, and Envoy all provide rate-limiting middleware, but the configuration details determine effectiveness.

Rate limiting keyed only on IP address is insufficient in environments where clients share egress IPs through NAT or corporate proxies. Token-keyed rate limiting - throttling per authenticated identity rather than per source IP - provides far more accurate enforcement and avoids penalizing legitimate clients who share an egress address with an abusive one. Payload size limits (configured via client_max_body_size in NGINX or the request_size_limit plugin in Kong) should be set per-route based on the expected maximum request body for that endpoint, not a global default that accommodates the largest possible body across all endpoints.

GraphQL APIs deserve specific mention. Unrestricted query depth and field breadth are a well-known attack vector. Gateway-level defenses - query depth limits, query complexity scoring, introspection disabling in production - should be part of every GraphQL deployment threat model.

Security Misconfiguration and Sensitive Data Exposure

OWASP API8 (Security Misconfiguration) and API3 (Broken Object Property Level Exposure) both manifest frequently at the gateway layer. Common misconfiguration patterns include: CORS policies that allow arbitrary origins (Access-Control-Allow-Origin: *) on authenticated endpoints, debug or admin endpoints exposed through the same gateway as production APIs without access restrictions, and verbose error responses that leak internal stack traces or internal service addresses.

Threat modeling sessions using STRIDE or the OWASP API threat model template should enumerate every route exposed through the gateway, annotate the expected caller identity and data sensitivity, and verify that CORS, authentication, and error-handling configurations match the intended trust model. Automated tools like 42Crunch API Security Audit and Vacuum (for OpenAPI linting with security rules) can supplement manual review by flagging missing authentication declarations or overly permissive CORS in API specifications before deployment.

Limits of Gateway Enforcement

Gateways are not a substitute for application-layer security. Encrypted-but-valid requests carrying malicious payloads in JSON bodies pass gateway inspection unless a WAF with deep payload inspection is integrated. Business logic flaws - accepting a negative quantity in an order to generate a refund, for example - are invisible to a gateway that validates structure but not semantics. The threat model must document these limits explicitly, so downstream services do not assume the gateway has sanitized inputs that it has only authenticated.