API Gateway Security Configuration Best Practices

OWASP's API Security Top 10 is the current industry reference for categorizing API risk. The list got its first major revision in June 2023, four years after the previous update. It gives us a shared vocabulary, and more practically, it maps specific gateway configuration decisions to specific real-world attack patterns.

Five categories are directly addressable at the gateway layer:

• API1 (Broken Object Level Authorization, or BOLA): Has held the number one spot since 2019. Fine-grained authorization enforcement at the gateway is the fix.
• API2 (Broken Authentication): Strong auth policies and proper token validation close this gap.
• API4 (Unrestricted Resource Consumption): The 2023 rename of "Lack of Resources and Rate Limiting." Rate limiting and throttling are the answer.
• API8 (Security Misconfiguration): Open CORS, verbose error messages, insecure defaults. Hardened gateway configuration addresses all of it.
• API9 (Improper Inventory Management): Forgotten endpoints, old API versions still live and accessible. Gateway-enforced routing and version deprecation policy fix this.

Two additions from the 2023 update deserve a flag:

• API6 (Unrestricted Access to Sensitive Business Flows): This one is tricky because the API is working exactly as designed. The abuse happens at scale. Rate limiting and behavioral monitoring are the gateway-layer responses.
• API10 (Unsafe Consumption of Third-Party APIs): A lot of organizations use third-party APIs. The data coming back from those APIs has to be validated just as rigorously as data from untrusted clients. Most teams don't do this.

Each section below calls back to the relevant OWASP ID so you always know which risk a given configuration decision is actually closing.

Authentication: enforcing verified identity on every request before anything else runs

No API route should be reachable without verified identity. Not "internal" endpoints. Not "low-risk" endpoints. None of them.

OAuth 2.0 paired with JWTs is the dominant standard combination in practice. JWTs must be validated on every request: signature, expiration, issuer. Not just on first contact and then cached indefinitely. That last part is where things get interesting — like a bouncer who checks your ID at the door but waves you through every room for the rest of the night without a second look.

Short JWT expiration times are genuinely useful. If a token gets stolen, short expiration limits the blast radius. Pair that with a token revocation mechanism and you have covered most of the common exploitation paths.

Now, the caching pitfall. When a cached JWT triggers an ALLOW response from an AWS API Gateway authorizer cache, the gateway can skip re-checking authorization for the specific resource being accessed. By default, AWS does not require the cache key to include the resource path and method. That means the default configuration can return ALLOW for a resource the token was never actually authorized to reach.

Teams spend real time chasing what looks like an application bug, only to trace it back to this exact default. The fix is straightforward: configure the cache key to include both method and path, or disable caching entirely for sensitive routes. But you have to know the default is wrong before you can fix it.

One more line worth drawing: the gateway should never issue or refresh access tokens. That belongs to a centralized authorization server. When you mix those responsibilities into the gateway, you increase attack surface and add complexity that creates new gaps faster than it closes old ones.

Credential stuffing and brute-force are authentication-layer attacks. Rate limiting on auth endpoints, which we cover below, is a direct complement to everything in this section.

Authorization: making sure authenticated identities can only reach what they're permitted to reach

Authentication answers "who are you?" Authorization answers "what are you allowed to do?" Gateways fail more often on the second question.

BOLA has sat at number one on the OWASP list since 2019. Object-level access checks get delegated to the application layer. The application layer gets them wrong sometimes. Sometimes is enough.

Least-privilege is the default posture. Default to deny. Require explicit grants for every sensitive operation. Grant the minimum scopes and permissions required per consumer, not broad permissions per user class.

Three authorization models a gateway can enforce:

• RBAC (Role-Based Access Control): The right choice for most standard consumer segmentation.
• ABAC (Attribute-Based Access Control): More granular. Makes decisions based on request context like time of request, IP address, or resource attributes.
• Scope-based authorization: The standard complement to OAuth 2.0 token flows.

Fine-grained authorization at the gateway is what makes BOLA prevention scalable. Trying to check object ownership in every downstream service independently is error-prone and inconsistent. You will miss something. You will not know you missed it until someone exploits it.

And circling back to the AWS caching pitfall from the previous section: a cached ALLOW that ignores the resource path is an authorization failure. It looks like an authentication problem. It is not. It lives in your gateway configuration, and the distinction matters because that's where the fix is.

Transport encryption: TLS configuration choices that actually matter

TLS is baseline. No production API gateway accepts unencrypted traffic. That part isn't the conversation worth having.

The decisions that actually require thought are about protocol versions and cipher suites.

Protocol versions. TLS 1.2 is the minimum acceptable version. TLS 1.3 is preferred. TLS 1.0 and 1.1 are deprecated and must be explicitly disabled. Many gateway defaults still allow them. Check yours before you assume otherwise.

Cipher suites. Disable weak and export-grade ciphers. Prefer forward-secret cipher suites. Forward secrecy means a compromised private key does not retroactively expose past sessions. That distinction matters more than it appears at first.

TLS termination at the gateway is a common pattern. It centralizes certificate management and relieves backend services of that overhead. But it creates a decision point: do you re-encrypt traffic between the gateway and your backends, or do you trust the internal network? In a zero-trust architecture, re-encryption or mTLS to backends is not optional. The next section covers exactly that.

The operational failure mode that breaks security most often isn't misconfigured cipher suites, though. It's expired certificates. Expired certificates cause outages. Outages pressure teams to disable enforcement temporarily. That temporary window becomes a breach window. Automate renewal. Treat certificate rotation as infrastructure, not a calendar reminder that gets snoozed.

Mutual TLS for service-to-service authentication in zero-trust environments

Standard TLS has the client verify the server's certificate. The server accepts any client that shows up. There's no cryptographic proof of who the client actually is. That works fine for a lot of web traffic. It is not sufficient for service-to-service authentication in a zero-trust model.

Mutual TLS (mTLS) requires both sides to present and verify X.509 certificates. Both parties prove who they are before any data moves. This eliminates password-based authentication vulnerabilities and creates a cryptographic audit trail.

Where does mTLS show up in practice?

• IoT device authentication
• B2B API integrations
• Internal service-to-service calls in zero-trust architectures

The gateway is the natural enforcement point for mTLS policy. You centralize certificate validation rather than distributing it across every backend service and hoping each team implements it consistently.

The implementation pitfall that bites teams hardest is certificate rotation timing. Teams running short certificate lifespans in Istio hit a frustrating pattern: a meaningful percentage of requests fail with certificate validation errors during rotation, because new certificates were issued but not yet distributed to all sidecars. The fix is to issue new certificates when current ones are halfway through their validity period. That creates an overlap window where both old and new certificates are valid simultaneously, and rotation stops generating errors. Obvious in hindsight. Less obvious at two in the morning when requests are failing and you're not sure why.

For anyone on AWS infrastructure: mTLS for Amazon API Gateway is generally available at no additional cost across commercial, GovCloud, and China regions. Configuration is available via console, CLI, SDK, or CloudFormation.

Rate limiting and throttling: the configuration decisions that stop abuse before it becomes a breach

In 2024, attackers sent over 5,000 requests per minute to Dell's API continuously for nearly three weeks before the activity was detected. By that point, 49 million customer records had been exfiltrated. The volume was high. The duration was long. The damage was done before anyone noticed.

That is what misconfigured rate limiting looks like at scale — a slow leak in a dam that nobody noticed until the valley was already flooded.

Rate limiting operates at multiple granularities, and you need all of them:

• Per-consumer: Prevents any single API key or token from running unlimited extraction.
• Per-route: Apply tighter limits on sensitive endpoints like auth flows, data exports, and account creation.
• Per IP address: Catches unauthenticated or distributed abuse.
• Global: Protects overall backend capacity from aggregate load.

Algorithm choice matters more than most people expect. Sliding window algorithms handle burst traffic more gracefully than fixed-window counters. Fixed-window counters can be gamed at window boundaries. A client who knows your window resets at the top of the minute can fire a burst at 11:59 and another at 12:00 and effectively double their allowed rate. Sliding windows close that gap.

Worth separating these two terms because conflating them leads to misconfiguration:

• Rate limiting: Hard cap. Requests above the limit are rejected.
• Throttling: Excess requests are queued or slowed rather than dropped. Appropriate for traffic that is bursty but legitimate.

Low-and-slow attacks like the Dell breach are specifically designed to stay under simple rate limit thresholds. The per-minute volume looks normal. The signal is in the duration and the pattern. Behavioral anomaly detection at the logging and monitoring layer is the necessary complement here. Rate limiting alone doesn't catch this. You need both.

Apply stricter limits to authentication endpoints. Brute-force and credential stuffing attacks are rate-based by nature. Throttle them hard.

Input validation and schema enforcement: rejecting malformed requests at the edge

The gateway rejects invalid requests. It does not log them and pass them through. The backend never sees them. That is the correct mental model.

Path traversal and SQL injection together account for nearly half of known API vulnerabilities by type. Both are detectable and rejectable at the gateway layer before they ever touch your backend.

Schema enforcement using OpenAPI or JSON Schema definitions is how you operationalize this:

• Reject payloads that exceed expected size limits
• Reject requests with unexpected or undeclared fields
• Enforce type checks. A field expecting an integer should never accept a string containing SQL. The schema itself blocks the injection attempt.
• Validate path parameters against allowed patterns. This directly addresses path traversal.

Validation and sanitization are not the same thing, and you need both. Validation rejects requests that don't conform to the schema. Sanitization strips or encodes dangerous characters in accepted inputs. It's defense-in-depth for what schema enforcement misses, and something always slips through.

API10 (Unsafe Consumption of Third-Party APIs) applies here in a direction most teams overlook. Responses coming back from upstream third-party APIs must be validated before being processed or forwarded. They are not trusted by default just because your system initiated the request.

There's also a secondary benefit worth mentioning. Schema enforcement at the gateway requires maintaining an accurate, current inventory of endpoints and their expected contracts. You cannot enforce what you haven't defined. The discipline of schema enforcement forces the inventory discipline as a side effect. That addresses API9 (Improper Inventory Management) without any extra work. Two problems, one configuration habit.

WAF integration and security headers: the configuration layer that catches what schema enforcement misses

Schema validation checks conformance to a contract. A WAF inspects payloads against known attack signatures and behavioral rules. They're solving different problems. Running one doesn't mean you can skip the other.

What a WAF at the gateway layer adds:

• Signature-based detection for SQLi, XSS, and known exploit patterns
• IP reputation filtering and geographic blocking
• Bot detection rules
• Custom rules for application-specific abuse patterns

AWS WAF attaches directly to API Gateway. Custom rules can filter on IP address, request patterns, or geographic origin before traffic ever reaches the backend. Having WAF available and leaving it on defaults is roughly equivalent to not having it — like installing a deadbolt and never turning the key. Teams do this more often than they admit, usually because WAF configuration feels like a separate project and keeps getting deferred.

CORS configuration is where API8 (Security Misconfiguration) shows up most often in practice. Wildcard origins are common in development environments. They allow any browser-based client to call the API. They're dangerous in production, and they migrate from development to production more often than anyone wants to admit. Usually right before a deadline.

The fix is straightforward:

• Explicitly whitelist allowed origins. No wildcards in production.
• Restrict allowed methods to only those the API actually uses.
• Restrict allowed headers to only those the API actually needs.

Security response headers are small configuration changes that tend to get skipped because they feel like housekeeping. They're not housekeeping.

• Content-Security-Policy: Limits what resources a browser will load, directly constraining the damage from any injected content that makes it through upstream controls.
• X-Content-Type-Options: Prevents browsers from MIME-sniffing responses away from declared content types.
• Strict-Transport-Security: Forces HTTPS for future requests, preventing protocol downgrade attacks.

None of these require significant effort to implement. All of them close real attack vectors.

The layered view is worth holding onto. Authentication, authorization, rate limiting, input validation, WAF, and security headers are not redundant. Each one operates on a different attack class. A request that bypasses rate limiting still hits schema validation. A payload that passes schema validation still hits the WAF. The layers aren't backup plans for each other. They're separate filters catching separate things. Configure all of them.