API Gateway Security

API Gateway Security involves protecting your APIs from unauthorized access, abuse, and attacks. Amazon API Gateway provides multiple layers of security controls.

Authentication & Authorization

• IAM Authorization: callers sign requests with SigV4; best for service-to-service
• Cognito Authorizer: validate JWT tokens from Cognito user pools
• Lambda Authorizer: custom auth logic (token-based or request-based)
• API Keys: for usage tracking and throttling, not security (keys are not secrets)
• Mutual TLS (mTLS): client certificate authentication for zero-trust API access

Protection Controls

• Throttling: rate limits per stage, per method, per API key to prevent abuse
• WAF Integration: attach AWS WAF rules for SQL injection, XSS, bot protection
• Resource Policies: IP whitelisting, VPC endpoint restrictions, cross-account access control
• Request Validation: validate request body, query strings, headers before reaching backend

How It Goes Wrong in Practice

The most instructive misconfiguration in API Gateway is the forgotten default endpoint. Every REST API gets an auto-generated execute-api URL, and it keeps working even after you put a custom domain in front of the API. Teams configure mutual TLS on the custom domain, or attach a WAF and strict resource policy there, and believe the API is locked down. Meanwhile the default endpoint still accepts requests with none of those domain-level protections, and its URL format is predictable enough that scanners find it. AWS documentation is explicit on this point: if you want clients to reach the API only through a custom domain with mutual TLS, you must disable the default execute-api endpoint. The second recurring failure is the authorizer gap. Authorization in API Gateway is configured per method, not per API, so a new route added under deadline pressure can ship with authorization set to NONE while every other route requires a Cognito or Lambda authorizer. Nothing in the deployment process flags the inconsistency; the API works, the tests pass, and one path is quietly open to the internet. Finally, teams regularly mistake API keys for an authentication mechanism. API keys exist for usage plans and throttling; they are sent in a plain header, often embedded in client applications, and should never be the only thing standing between the internet and your backend.

Practical Check: Review Authorizers and mTLS Setup

List the authorizers configured on a REST API to confirm what is actually protecting it:

aws apigateway get-authorizers --rest-api-id a1b2c3d4e5

Then, in the console, review each resource and method under the API and check the authorization setting on every method, looking specifically for methods set to NONE that are not intentionally public. If you are deploying mutual TLS, the verified requirements are: a Regional custom domain name, a certificate for that domain in AWS Certificate Manager, a truststore file (PEM bundle of your CA chain) uploaded to S3, and the TLS_1_2 security policy on the domain. And remember the step that closes the loop: disable the default endpoint so mTLS cannot be bypassed.

Frequently Asked Questions

Are API keys a security control?
No. AWS positions API keys for usage tracking and throttling through usage plans. They are not secrets in any strong sense and provide no identity assurance. Use IAM authorization, Cognito user pools, Lambda authorizers, or mutual TLS for actual authentication and authorization.

Does mutual TLS work everywhere in API Gateway?
No. Mutual TLS requires a Regional custom domain name and is not supported for private APIs. Also note that API Gateway validates the client certificate chain against your truststore but does not check certificate revocation; if you need revocation checks, implement them in a Lambda authorizer that inspects the forwarded certificate.

What happens if a certificate in my truststore is invalid?
API Gateway returns warnings when you create or update a domain with a problematic truststore, but it only warns at update time: it does not notify you later when a previously uploaded certificate expires. Track truststore certificate expiry yourself, and version the truststore object in S3 so you can roll back cleanly.

Is throttling enough to stop abuse?
Throttling protects your backend from being overwhelmed and limits the blast radius of runaway clients, but it does nothing about malicious payloads. Pair stage and method throttling with AWS WAF for injection and bot patterns, and with request validation so malformed requests are rejected before they invoke your integration.