API Gateway Security Configuration: AWS API Gateway, Azure APIM, and Shadow API Discovery for Enterprise Environments
Retool's new app builder is where AI-generated code ships safely
Building apps with AI is easy. Getting them to production safely is another story.
API gateways are perimeter security controls, not comprehensive API security solutions: they protect the routes registered in the gateway configuration with the security controls configured on those routes. Backend services with public endpoints that bypass the gateway, API versions that were deprecated but never removed from the routing table, and gateway routes configured without authentication or rate limiting create the gaps that OWASP API Security Top 10 findings appear in.
The security configuration work has two components: hardening the gateway configuration for routes that exist (authentication, rate limiting, schema validation, WAF), and discovering the APIs that bypass the gateway entirely (shadow API discovery). Both are required — hardening the gateway without addressing shadow APIs leaves the backend directly exposed, and shadow API discovery without gateway hardening means the gateway-routed APIs remain unprotected.
Gateway hardening: authentication and rate limiting as first priorities
Before addressing shadow APIs, every route registered in the gateway should have an authorization type and a rate limit. Exporting all routes and auditing them against these two requirements reveals the most urgent gaps: unauthenticated routes that should require JWT or API key validation, and routes without usage plans that an attacker can abuse at unlimited volume. This section covers the specific AWS API Gateway and Azure APIM configuration steps for JWT authorizers, Cognito User Pool authorizers, usage plans, and access log enabling, in the order that provides the most security value per change.
Audit every API route for authentication and rate limiting before adding schema validation
Export the full list of API Gateway routes (aws apigateway get-resources in AWS, az apim api operation list in Azure) and for each route, document the authorization type and whether a usage plan or rate limit is applied. Routes with authorization type NONE on AWS API Gateway or no validate-jwt policy on Azure APIM are unauthenticated APIs — identify each one and determine whether this is intentional (public APIs requiring no authentication) or a misconfiguration. Create a remediation list of routes that should be authenticated but are not, and add authentication to each in priority order based on the sensitivity of the data exposed. Similarly, identify routes without rate limiting — APIs with no rate limit are vulnerable to DoS through API abuse.
Enable comprehensive API access logging before shadow API discovery
Enable full API Gateway access logging to CloudWatch Logs (AWS) or Azure Monitor (Azure) before beginning shadow API discovery — the access logs are the primary tool for identifying zombie APIs and can reveal whether shadow APIs are receiving traffic that would otherwise be visible in the gateway logs. On AWS API Gateway, configure CloudWatch logging on each stage with a log format that includes request path, method, status code, response time, and the identity of the caller (API key ID or JWT sub claim). The access logs reveal traffic patterns including high-volume requests from single IPs (abuse candidates), requests to paths not in the official API specification (undocumented endpoints), and callers using deprecated authentication methods (zombie API consumers).
Shadow API discovery: finding exposure that bypasses the gateway
Shadow APIs exist because cloud development velocity outpaces API registration processes: a developer creates a Lambda function URL for testing, a microservice gets a public Application Load Balancer for a sprint demo, and neither is removed or routed through the gateway after the task is complete. Finding them requires combining cloud inventory exports with external scanning tools such as Shodan or Censys, then reconciling the results against the gateway's registered integration targets. This section also covers the infrastructure policy controls — AWS SCPs and Azure Policy — that prevent new shadow APIs from being created without a gateway integration step.
Combine cloud inventory export with external network scanning for comprehensive shadow API discovery
Shadow API discovery requires combining internal cloud inventory data with external network scanning. From internal inventory: export all AWS API Gateway stage URLs, Application Load Balancer DNS names, Lambda function URLs, EC2 elastic IPs, and RDS publicly accessible instances, plus all Azure App Service custom domains, API Management endpoints, and Azure Functions HTTPS URLs. For each compute resource, check whether it has a public IP or DNS name that is not registered in the API gateway as an integration target. From external scanning: use Shodan or Censys to search for your organization's ASN, IP ranges, and domain patterns for HTTP/HTTPS services, comparing against your known internal inventory. Services appearing in external scan results but not in your internal inventory are shadow APIs requiring immediate investigation.
Implement a mandatory API registration process to prevent new shadow APIs
Prevent future shadow API creation by requiring all new API deployments to go through an API registration process that includes gateway integration as a required step before external access is permitted. In AWS Organizations, use a Service Control Policy (SCP) that denies ec2:AuthorizeSecurityGroupIngress for port 80 and 443 from 0.0.0.0/0 except through approved gateway patterns, preventing developers from directly exposing services to the internet without going through the API gateway. In Azure, use Azure Policy to require that App Service applications have network restrictions configured. Integrate API registration into the CI/CD pipeline: require that each new backend service deployment includes an API gateway route configuration in the infrastructure-as-code repository, reviewed and approved through the same PR process as application code.
Briefings like this, every morning before 9am.
Threat intel, active CVEs, and campaign alerts, distilled for practitioners. 50,000+ subscribers. No noise.
The bottom line
API gateway security configuration provides centralized authentication, rate limiting, schema validation, and WAF protection — but only for APIs routed through the gateway. Shadow API discovery identifies backend services directly exposed to the internet that bypass all gateway controls, and zombie API analysis identifies deprecated API versions still accessible with older authentication mechanisms. The security baseline requires authentication on every gateway route (JWT, API key, or IAM authorization), rate limiting per consumer to prevent abuse, request schema validation to reject malformed inputs at the gateway, and a continuous shadow API discovery process using cloud inventory export and external network scanning. Prevent future shadow APIs with infrastructure policy controls that prevent public exposure of backend services without gateway integration.
Frequently asked questions
How do I configure JWT authorization on AWS API Gateway?
Configure JWT authorization on a REST API Gateway using a Lambda authorizer or on an HTTP API Gateway using the native JWT authorizer. For HTTP API Gateway (the simpler approach): go to Authorization in the API Gateway console, create a JWT authorizer, and configure the Issuer URL (the OIDC discovery endpoint for your identity provider, such as https://cognito-idp.us-east-1.amazonaws.com/USER_POOL_ID for Cognito) and the Audience (the app client ID that the token was issued for). Attach the authorizer to each route that requires authentication. The gateway validates the JWT signature, expiration, issuer, and audience on every request before forwarding to the integration target. For REST API Gateway: use a Cognito User Pool authorizer (simpler, natively supports Cognito tokens) or a Lambda authorizer that validates any JWT format. The Lambda authorizer receives the Authorization header and returns an IAM policy allowing or denying invocation of the API method.
How do I configure rate limiting on AWS API Gateway to prevent API abuse?
Configure API Gateway rate limiting at two levels: default stage-level throttling and usage plan-based throttling for individual API consumers. Set the default throttling limits on the API stage in API Gateway Settings: Throttling Rate (requests per second, such as 1000 RPS) and Throttling Burst (the maximum concurrent requests before throttling, such as 500). For per-consumer rate limiting: create Usage Plans with specific rate and burst limits, create API keys for each consumer, associate the API keys with the usage plan, and associate the usage plan with the API stage. API consumers include their API key in the x-api-key header, and API Gateway enforces the usage plan limits for that key independently of other consumers. A consumer exceeding their rate limit receives a 429 Too Many Requests response without affecting other consumers' limits.
How do I configure Azure API Management security policies for JWT validation and IP filtering?
Configure Azure APIM security using inbound policies in the policy editor. JWT validation using the validate-jwt policy: add to the inbound section of the API or operation: the validate-jwt element with header-name Authorization, failed-validation-httpcode 401, and openid-config-url pointing to the OIDC discovery endpoint. The policy extracts the Bearer token from the Authorization header and validates signature, expiration, and claims against the identity provider's public keys. IP filtering using the ip-filter policy: add ip-filter action=allow addresses block inside inbound to whitelist specific IP addresses or CIDR ranges, or ip-filter action=forbid to block specific IPs. Rate limiting per subscriber key: use rate-limit-by-key calls=100 renewal-period=60 counter-key=@(context.Subscription.Id) to limit each subscriber to 100 calls per 60 seconds. Combine these policies in the inbound section of the All APIs scope to apply them globally across all APIs in the APIM instance.
How do I discover shadow APIs that bypass the API gateway?
Shadow API discovery requires network scanning combined with cloud inventory analysis. For cloud environments: export all load balancers, EC2 instances, Lambda function URLs, App Service endpoints, and Cloud Run services from AWS and Azure using the CLI or cloud inventory tools. For each public-facing endpoint, check whether it is registered as an API Gateway integration target — endpoints with public access that are not gateway integration targets are potential shadow APIs. Use Nmap to scan the same CIDR ranges your organization uses for services and identify HTTP/HTTPS services on non-standard ports (8080, 8443, 3000) that may be development or internal APIs exposed externally by misconfiguration. Analyze API Gateway and load balancer access logs for requests to paths not in the official API specification — these may be undocumented endpoints. Use an EASM (External Attack Surface Management) tool such as Censys or Shodan to search for your organization's IP ranges and identify internet-facing services that your internal inventory does not account for.
How do I integrate AWS WAF with API Gateway for OWASP protection?
Integrate AWS WAF with an API Gateway REST API by creating a WAF Web ACL in the same region as the API, adding the AWS Managed Rules - Core Rule Set (which covers OWASP Top 10 categories including SQL injection, XSS, and remote file inclusion) as a rule group, and associating the Web ACL with the API Gateway stage in the WAF console. The AWS Managed Rules - Known Bad Inputs rule group blocks requests containing known exploit payloads. The Amazon IP Reputation List blocks IPs associated with malicious actors. After associating the Web ACL, all requests to the API Gateway stage are filtered through WAF before reaching the API integration. Enable WAF sampled requests and WAF logs to identify blocked request patterns and tune rules to reduce false positives from legitimate API traffic patterns. For HTTP API Gateway (which does not natively support WAF), place a CloudFront distribution in front of the HTTP API and attach the WAF Web ACL to the CloudFront distribution.
How do I identify and retire zombie APIs?
Identify zombie APIs through access log analysis combined with API inventory comparison. Export access logs from API Gateway (enable CloudWatch logging with full request and response logging), then query the logs for all request paths and HTTP methods that received traffic in the last 90 days. Compare this list of active paths against the current OpenAPI specification of the API — paths present in the access logs but absent from the current specification are either undocumented endpoints (shadow APIs) or deprecated endpoints still in use (zombie APIs). For deprecated API versions (v1, v2 still receiving traffic alongside v3), contact the API consumers appearing in the access logs (identifiable via API key or JWT sub claim) to plan migration before retirement. Set a deprecation notice with a concrete end-of-life date for each zombie API version, enforce the deadline by returning 410 Gone responses on the retirement date, and monitor for any consumers still sending traffic to the retired endpoint for 30 days after retirement.
How do I enforce OpenAPI schema validation at the API gateway to prevent injection attacks?
Enable request body and parameter validation at the API gateway to reject malformed requests before they reach backend services. On AWS REST API Gateway: create a Model in the API Gateway console with the JSON schema for each request body, assign the model to the method's request body via Method Request, and enable Request Validator set to Validate body, query string parameters, and headers on the method. On AWS HTTP API Gateway: configure request validation in the route settings using the $request.body schema. On Azure APIM: use the validate-content policy with schema-validation set to prevent or detect mode in the inbound section. Schema validation rejects requests with missing required fields, incorrect data types, or unexpected additional fields, blocking common injection attacks where payloads exceed expected field formats before the backend application processes the malformed data. Keep the OpenAPI schema synchronized with the actual API contract to prevent rejecting legitimate requests when the schema drifts from the implementation.
Sources & references
Free resources
Critical CVE Reference Card 2025–2026
25 actively exploited vulnerabilities with CVSS scores, exploit status, and patch availability. Print it, pin it, share it with your SOC team.
Ransomware Incident Response Playbook
Step-by-step 24-hour IR checklist covering detection, containment, eradication, and recovery. Built for SOC teams, IR leads, and CISOs.
Get threat intel before your inbox does.
50,000+ security professionals read Decryption Digest for early warnings on zero-days, ransomware, and nation-state campaigns. Free, daily, no spam.
Unsubscribe anytime. We never sell your data.
Founder & Cybersecurity Evangelist, Decryption Digest
Cybersecurity professional with expertise in threat intelligence, vulnerability research, and enterprise security. Covers zero-days, ransomware, and nation-state operations for 50,000+ security professionals every morning.
Win a $2,495 Black Hat pass.
Full-access to Black Hat USA 2026 in Las Vegas. Subscribe free to enter.