API Gateway Security: Policies, WAFs and Limits

Give the gateway a defined job

API gateway security is strongest when the gateway owns controls it can observe reliably: TLS termination, coarse authentication, route matching, body limits, quotas, and central logging. Write down each policy's scope and which service still makes the final authorization decision. A gateway may know that a token is valid, but the service usually knows whether a particular invoice belongs to that caller.

List every route and method, including legacy versions, health paths, callbacks, and administrative endpoints. Compare the deployed gateway table with the service inventory and OpenAPI document. A new route can bypass policy if it is exposed through a second host or an overly broad wildcard. Test the route from outside the trusted network, not only through an internal development path.

Authenticate and forward identity safely

Validate token issuer, audience, expiry, and signature at the intended enforcement point. Strip any client-supplied identity headers before injecting verified claims for downstream services. If a service is reachable directly, it must either validate credentials itself or be isolated so requests can arrive only from the trusted gateway. Test wrong-audience and missing tokens on every sensitive route.

Keep user identity separate from gateway workload identity. A valid gateway-to-service connection should not automatically authorise a request for another tenant's data. Choose narrowly scoped claims and avoid forwarding full tokens to services that do not need them. Review token leakage in access logs and tracing headers.

Set limits based on work

Define request byte, connection, and rate limits for each class of endpoint. A read of a cached status object and a report export have different costs. Apply limits by authenticated client or account where possible; an IP-only rule can penalise many users behind one network and can be evaded by distributed callers. Return a documented 429 response and a useful retry signal when throttling is intended.

A gateway request count cannot see every expensive database operation or GraphQL resolver. Add service-side page-size, query-cost, and concurrency bounds for heavy workloads. Test both a burst of ordinary calls and a single worst-case request. Watch latency and dependency saturation during controlled tests, then adjust quotas before a real incident.

Treat WAF rules as one layer

A web application firewall can reject known malicious patterns and provide emergency controls, but it does not understand every business authorization rule. A well-formed request for another user's account can pass all syntax filters. Tune rules against representative traffic and record false positives. Use temporary blocks with an expiry and a ticket so an emergency exception does not become the permanent security policy.

If a WAF inspects JSON, check its body-size and parser limits. An attacker may place a payload beyond the inspected prefix or use an unexpected content type. Ensure the application still validates input and uses safe query APIs. Monitor rule decisions together with service outcomes to see whether a blocked pattern was actually relevant.

Keep policy and contract in sync

Document expected authentication, limits, and errors in OpenAPI where they help clients. Run a contract scan during development to catch missing declarations, then compare the candidate document to gateway configuration at deployment. APISAST can review design signals in OpenAPI and Swagger. It cannot prove a gateway policy is loaded, a WAF blocks an attack, or a service checks object ownership.

Use staged rollouts for new rules. First log what the policy would block, review legitimate clients, then enforce with a rollback path. Version policies alongside service changes and test a route table diff in CI. A clear owner should approve changes that widen exposure or remove authentication. Drift between code, contract, and gateway is often more dangerous than a missing keyword in documentation.

Example: a partner import endpoint

Consider POST /imports used by a small set of partners. The gateway can require a partner token, restrict body size, apply a per-client request quota, and forward a verified client identifier. The service must still check that the partner may import into the requested account and that uploaded data meets domain rules. A WAF may block a known payload pattern, but it cannot know whether the account relationship is valid.

Test a valid import, another partner's account ID, an oversized body, an expired token, and repeated imports. Check the outcome at both gateway and service logs. If the gateway rejects a request, the service should not record a successful import. If the service rejects a valid-looking request, the gateway log alone will not explain why; correlation IDs must bridge the two layers.

Prepare for gateway failure and change

Decide how authentication and quota checks behave if an external policy service is unavailable. Sensitive routes should not silently become open because a helper timed out. Document the failure policy and test it in a safe environment. Watch for configuration propagation delays during rollout and make rollback measurable.

Review direct service exposure after infrastructure changes such as a new load balancer, ingress controller, or health-check host. A route that was reachable only through the gateway yesterday may be public after a networking change. Include an external route probe and an inventory comparison in deployment checks. That test closes a gap no OpenAPI description can see.

Continue the work

Use these guides to put the checks into your API review process:

• Rate limiting strategies
• Public API authorization
• Review an API contract

Primary reference: OWASP API8 Security Misconfiguration.

APISAST reviews OpenAPI and Swagger contracts for documented design signals. Confirm authorization, enforcement, performance, and abuse controls against a running service.