API Gateway Security: The Perimeter Most Organizations Forget to Harden

#The forgotten perimeter

I've been running engagements on this for a few years now. The shortcut you'd expect to exist doesn't.

An API gateway sits in front of your backend services. Every API request from customers, partners, or internal clients passes through it. The gateway handles:

• Authentication (verifying API keys, JWT tokens, OAuth)
• Authorization (deciding who can call what)
• Rate limiting (preventing abuse)
• Request routing (picking the right backend service)
• Transformation (modifying requests/responses)
• Observability (logging, metrics, tracing)
• Security features (WAF integration, TLS termination)

For many organizations, the API gateway is the practical edge of their infrastructure. Its configuration determines what customers can access and how.

It's also, in our penetration testing experience, consistently under-hardened. The gateway is often set up early in a product's lifecycle, configured for convenience during development. And never re-audited as the product scales. By the time an organization has enterprise customers and regulatory obligations, the gateway is running configurations that would fail a security review.

This post covers the specific attack patterns we find on API gateways during audits, the hardening approach for the major products (Kong, Apigee, AWS API Gateway, Traefik, Envoy, Tyk, Zuul). And the architectural decisions that separate secure gateways from risky ones.

#The major players

#Kong

Self-hosted (Kong Gateway) or managed (Kong Konnect). Lua-based plugin architecture. One of the most popular open-source API gateways. Used by many enterprises.

Strengths:

• Mature plugin ecosystem
• High performance
• Strong community

Security concerns:

• Self-hosted deployments often misconfigured
• Admin API exposure is a recurring finding
• Plugin security varies

#Apigee

Google-owned. Managed service with on-prem option. Enterprise-focused. Strong API management features beyond pure gateway.

Strengths:

• Enterprise feature completeness
• Analytics and monetization
• Google-backed

Security concerns:

• Complex enough that misconfiguration happens
• Policy editing is a high-privilege operation

#AWS API Gateway

AWS-managed. Deep integration with AWS services. REST, HTTP, and WebSocket APIs.

Strengths:

• No infrastructure to manage
• IAM integration
• AWS ecosystem benefits

Security concerns:

• Specific misconfigurations common
• Resource policies complex
• Mixed REST vs HTTP API security models

#Traefik

Self-hosted. Cloud-native focus. Popular for Kubernetes environments.

Strengths:

• Kubernetes-native
• Simple configuration
• Good TLS handling

Security concerns:

• Admin API exposure risk
• Middleware configuration complexity

#Envoy

Self-hosted. Low-level proxy used by Istio, Emissary-ingress, and many service meshes.

Strengths:

• Extremely flexible
• Used in many production systems

Security concerns:

• Configuration complexity
• Used directly by experts only

#Tyk

Self-hosted or managed. Popular in certain sectors.

#Zuul

Netflix open-source. Java-based. Less common outside JVM shops.

#MuleSoft

Salesforce-owned. Enterprise-focused API management.

#Attack pattern 1: Admin API exposure

Most API gateways have an admin API. A management interface used to configure routes, plugins, authentication, etc. Separately from the data plane (where customer traffic flows), the admin API is a control plane.

The misconfiguration: admin API bound to 0.0.0.0 and exposed to the internet, with weak or no authentication.

Common patterns:

#Kong admin API

Kong's admin API runs on port 8001 by default, intended to be internal-only.

Incorrect deployment:

docker run -p 8000:8000 -p 8001:8001 kong:3 # admin port exposed!

Any attacker finding port 8001 exposed can:

• List all routes and services
• Modify route configurations
• Install malicious plugins
• Disable authentication
• Extract credentials from consumer configurations

Shodan queries for Kong admin API signatures find thousands of exposed instances.

Correct deployment:

# Bind admin API to internal network only
KONG_ADMIN_LISTEN="127.0.0.1:8001"

# Or use Kong's RBAC and enterprise authentication for admin API

#AWS API Gateway admin via console / API

AWS API Gateway is managed via AWS Console and AWS APIs. Administrative access controlled by IAM.

Common misconfiguration:

• IAM users/roles with apigateway:* permissions beyond what's needed
• ApiGatewayAdministrator managed policy attached too broadly
• Access keys in hands of developers who need read access only

Correct approach:

• Specific IAM permissions per role
• CloudTrail monitoring of API Gateway changes
• MFA for API Gateway administrative changes

#Traefik dashboard

Traefik's dashboard displays all routes, middleware, and services. Often exposed accidentally.

Common misconfiguration:

# dangerous
api:
  dashboard: true
  insecure: true # exposes dashboard without auth

Correct:

api:
  dashboard: true
  insecure: false # requires auth via router config

#Attack pattern 2: Weak authentication on exposed APIs

API gateways handle authentication. Common authentication models:

• API keys. Simple strings passed in headers
• OAuth 2.0 / OIDC. Token-based auth
• JWT. Self-contained signed tokens
• Mutual TLS (mTLS). Client certificates
• HMAC signatures. Signed requests
• Basic auth. Username/password (deprecated)

Common issues:

#API keys in URL parameters

https://api.example.com/data?api_key=sk_live_abc123

API keys in URLs get:

• Logged in server access logs
• Saved in browser history
• Included in HTTP Referer headers
• Captured by proxy servers
• Stored in browser bookmarks

Fix: API keys in Authorization header or custom header:

Authorization: Bearer sk_live_abc123

#Short, predictable API keys

Some gateways generate short API keys (16 characters or less). Brute-force against rate-limited endpoints is possible given enough time.

Fix: API keys should be 32+ random bytes, generated securely.

#Shared API keys across customers

Single API key used by multiple customers means compromise affects many. Lateral blast radius.

Fix: per-customer keys at minimum.

#No key rotation

Keys that never change mean old compromises (old employees, old partners, old systems) have persistent access.

Fix: documented rotation schedule and process.

#JWT signature validation bypasses

JWT authentication has specific failure modes:

• alg: none. Some libraries accept unsigned JWTs. Attacker forges tokens by setting alg: none.
• Weak signing secrets. HMAC-based JWTs with weak secrets can be cracked and forged.
• Algorithm confusion. Attacker substitutes RS256 with HS256 using the public key as the HMAC secret. If the gateway doesn't validate the expected algorithm, this works.
• Missing iss or aud validation. Accepting tokens from any issuer or for any audience
• Missing expiration validation. Expired tokens accepted

Fix:

• Explicitly validate expected algorithm (don't trust JWT header)
• Strong secrets for HMAC algorithms (64+ random bytes)
• Validate iss, aud, exp, nbf claims
• Use established JWT libraries, not hand-rolled parsers

#Attack pattern 3: Authorization bypass via routing tricks

API gateways route requests to backend services based on path, headers, and other attributes. Routing can be manipulated.

#Path traversal in routing

# Gateway config: /api/v1/users/* → user-service
# Gateway config: /api/v1/admin/* → admin-service (with auth check)

# Attack: path traversal to reach admin without going through auth
GET /api/v1/users/./admin/users → might route to admin-service

Different gateways normalize paths differently. URL-encoding tricks (%2e%2e%2f for ../) can fool some normalizers.

#Host header manipulation

# Gateway uses Host header for routing
Host: internal-admin.example.com # attacker-controlled

# Gateway forwards to internal admin service based on Host

#X-Forwarded-For spoofing

If gateway uses X-Forwarded-For for authentication ("trust requests from 10.0.0.0/8"):

# Attacker from external IP
X-Forwarded-For: 10.0.0.5 # claims to be internal

Gateway accepts as trusted, forwards to backend with trust.

Fix:

• Strict path normalization with denial on ambiguous requests
• Host header validation against allowlist
• Trusted-proxy configuration so client-provided X-Forwarded-For is ignored
• Tests for routing edge cases

#Attack pattern 4: Backend bypass

API gateway provides authentication and rate limiting. Backend services trust that the gateway has done the work.

The failure: backend services reachable directly (bypassing the gateway).

Common scenarios:

#Backend on public IPs

Services behind the gateway are deployed on public IPs, not private network. Attacker who discovers the backend URL (via DNS enumeration, SSL certificate transparency, previous compromise) can call it directly.

# Intended: customer → gateway → backend
# Actual: attacker directly → backend, skipping gateway

#Admin / debug endpoints on backends

Backend services have admin endpoints (/admin, /debug, /metrics) that aren't routed through the gateway. Direct access to backend bypasses auth.

#Kubernetes services without network policies

In Kubernetes, backend services may be reachable from any pod in the cluster, even those not supposed to access them.

Fix:

• Backend services in private network only. Only gateway can reach them
• Mutual TLS or IP restriction. Backend only accepts traffic from gateway
• Network segmentation (Kubernetes NetworkPolicies, AWS Security Groups, etc.)
• Regular audit. Try to reach backends from external IPs, should fail

#Attack pattern 5: Rate limiting bypasses

Rate limiting is a core gateway feature. Common bypasses:

#IP-based rate limit with header spoofing

# Gateway rate limits by X-Forwarded-For
# Attacker rotates X-Forwarded-For values
curl -H "X-Forwarded-For: 1.2.3.4" https://api.example.com/resource
curl -H "X-Forwarded-For: 1.2.3.5" https://api.example.com/resource
...

If gateway trusts client-provided X-Forwarded-For, each request appears to come from a different IP, bypassing per-IP rate limits.

#API key rotation for bypass

Attacker creates multiple free-tier API keys, rotates between them to multiply rate limits.

#HTTP/1.1 vs HTTP/2 / HTTP/3 differences

Some gateways implement rate limiting at a specific protocol layer. HTTP/2 and HTTP/3 can bypass rate limits that apply only to HTTP/1.1 (or vice versa).

#Distributed rate limits without shared state

Multi-instance gateways that rate limit per-instance (instead of using shared state like Redis) allow attackers to spread traffic across instances.

Fix:

• Rate limit on authenticated identity (API key, JWT subject) where possible
• IP allowlist of trusted proxies. Ignore client-provided X-Forwarded-For except from allowlisted sources
• Distributed rate limiting with shared state
• Multi-dimensional rate limiting (per-IP + per-key + global)

#Attack pattern 6: CORS misconfiguration

API gateways often handle CORS for their backend services.

Common bugs:

• Access-Control-Allow-Origin: * with Access-Control-Allow-Credentials: true. Actually rejected by browsers but some gateways output it. Can enable attacks via specific edge cases
• Reflecting any Origin header as the allowed origin. Allows credentialed cross-origin requests
• Allowing null origin. Null can come from sandboxed iframes or local files
• Subdomain wildcards that include untrusted subdomains

Fix:

• Specific allowed origins (no wildcards with credentials)
• Origin validation against allowlist, don't reflect
• Don't allow null origin
• Audit allowed origins for subdomain risk

#Attack pattern 7: Gateway plugin vulnerabilities

Gateways with plugin ecosystems (Kong, Apigee, Envoy filters) inherit plugin security risks.

Kong plugin examples:

• Third-party community plugins with vulnerabilities
• Custom plugins written in Lua without security review
• Plugin chains that don't validate input between plugins

Apigee policy examples:

• Custom JavaScript policies with injection vulnerabilities
• External service callouts without SSRF protection
• Fault rules that reveal internal errors to clients

Fix:

• Review all installed plugins
• Audit custom plugin code
• Keep plugins updated
• Minimize plugin usage

#Attack pattern 8: Credential leakage in gateway configs

Gateway configurations often contain secrets:

• Backend service credentials
• Third-party API keys
• Database connection strings
• Signing secrets for JWT validation

Common exposure:

• Configs committed to git with plaintext secrets
• Gateway admin API responses that include secrets
• Logs that capture request/response with secrets in headers
• Backup / export files with secrets

Fix:

• Use gateway's secrets management (Vault integration, cloud secret managers)
• Never commit configs with secrets
• Redact secrets in logs
• Secure backup files

#Attack pattern 9: Error message leakage

Gateway error messages can leak information:

• Internal service names
• Backend IPs
• Stack traces
• Configuration details
• Version information

Common misconfigurations:

• Default error pages with verbose output
• Gateway version in response headers (Server: Kong/3.2.0)
• Upstream connection errors including backend URLs
• Uncaught exceptions with stack traces

Fix:

• Custom error pages with generic messages
• Remove version headers
• Log detailed errors server-side, return generic to client
• Test error scenarios explicitly

#Attack pattern 10: Request / response manipulation

Gateways often transform requests and responses. Transformations can introduce vulnerabilities:

• Header injection if headers built from user input
• Path rewrites that enable SSRF if target URLs use user data
• Response rewrites that expose internal data
• Caching misconfigurations that cache per-user data globally

Fix:

• Strict input validation before transformations
• No user data in routing/rewriting decisions
• Cache keys include user identity for user-specific data
• Test transformations against injection patterns

#The hardening checklist

For any API gateway in production:

#Administrative access

• [ ] Admin API not exposed to public internet
• [ ] Admin access requires strong authentication
• [ ] Admin access logged
• [ ] MFA on administrative actions
• [ ] Change management for gateway config modifications

#Authentication

• [ ] No API keys in URLs
• [ ] Keys generated with sufficient entropy
• [ ] Per-customer or per-application keys
• [ ] Key rotation schedule
• [ ] JWT validation comprehensive (alg, iss, aud, exp)
• [ ] No alg: none accepted

#Authorization

• [ ] Path normalization rigorous
• [ ] Host header validation
• [ ] X-Forwarded-For only from trusted proxies
• [ ] Route access controls tested from edge cases

#Backend protection

• [ ] Backend services not publicly reachable
• [ ] Mutual TLS or equivalent between gateway and backend
• [ ] Network policies enforcing traffic flow
• [ ] Direct backend access tested (should fail)

#Rate limiting

• [ ] Rate limits on identity, not IP
• [ ] Distributed state for multi-instance gateways
• [ ] Multi-dimensional limits
• [ ] Burst handling tested

#CORS

• [ ] Specific allowed origins (no wildcards with credentials)
• [ ] No origin reflection
• [ ] Regular origin audit

#Plugins / policies

• [ ] All installed plugins reviewed
• [ ] Custom plugin code audited
• [ ] Plugins updated
• [ ] Third-party plugins scrutinized

#Configuration

• [ ] No secrets in config files in git
• [ ] Vault or cloud secrets manager integration
• [ ] Error messages generic
• [ ] Version headers removed
• [ ] Logs redacted for sensitive data

#Monitoring

• [ ] Gateway logs to SIEM
• [ ] Anomaly detection on traffic patterns
• [ ] Alerts for configuration changes
• [ ] Regular security scans of gateway endpoints

#Kong-specific hardening

# kong.conf
admin_listen = 127.0.0.1:8001 # bind admin API to localhost
admin_ssl_cert = /certs/admin.crt
admin_ssl_cert_key = /certs/admin.key

Enforce_rbac = on # enforce role-based access on admin API

Headers = server_tokens=off # remove version header

Log_level = notice

Plus:

• Use Kong's built-in plugins for rate limiting, auth, request transformation
• Prefer Enterprise features (Kong Konnect) for production
• Review third-party plugins carefully

#AWS API Gateway-specific hardening

• Use IAM authorization for admin access
• Resource policies restrict API access by IP/principal
• Use WAF for additional protection
• Enable CloudTrail logging
• Use CloudWatch alarms for anomalies
• REST APIs offer more security features than HTTP APIs (choose REST for security-sensitive use cases)

#Apigee-specific hardening

• RBAC for policy management
• Analytics for anomaly detection
• Shared flows for consistent security enforcement
• OAuth v2 policy properly configured
• Target server credentials via KVM (key-value map)

#Traefik-specific hardening

api:
  dashboard: true
  insecure: false # dashboard requires router with auth

Http:
  routers:
    dashboard:
      rule: Host(`traefik.example.com`)
      service: api@internal
      middlewares:
        - auth-middleware # require auth
  middlewares:
    auth-middleware:
      basicAuth:
        users:
          - "admin:$2a$10$..." # htpasswd-generated

#For small startups

• Start with a managed API gateway (AWS API Gateway, Google Cloud API Gateway)
• Don't self-host unless you've DevOps capability
• Basic auth setup: API keys per customer, rate limiting, CORS
• Security headers configured
• Logs to cloud-native logging (CloudWatch, etc.)

#For mid-size companies

• Kong or Apigee depending on feature needs
• Dedicated API security program
• Regular penetration testing
• WAF integration (CloudFront, Cloudflare, Imperva)
• Integration with IAM

#For enterprises

• Full API management platform (Apigee, MuleSoft, or Kong Enterprise)
• API governance committee
• API design review board
• Formal security review for new APIs
• Continuous monitoring
• Threat modeling for each significant API

#For Valtik clients

Valtik's API security audits include gateway configuration review:

• Gateway-specific configuration audit (Kong, Apigee, AWS API Gateway, others)
• Authentication and authorization review
• Routing and rewriting security
• Plugin/policy audit
• Backend bypass testing
• Rate limiting effectiveness
• CORS and header configuration
• Error handling review

If you run an API gateway in production and haven't had an explicit security review, reach out via https://valtikstudios.com.

#The honest summary

API gateways are central to modern service architectures. Their security is central to the security of everything behind them. The patterns in this post. Admin API exposure, weak auth, backend bypass, rate limit evasion, CORS issues, plugin vulnerabilities. Appear in every unaudited gateway deployment.

Treat your gateway as Tier-0 infrastructure. Audit it like you'd audit your database or your directory service. Because functionally, it's. It's the edge that gates access to everything else.

#Sources

1. Kong Gateway Documentation
2. Apigee Documentation
3. AWS API Gateway Documentation
4. Traefik Documentation
5. OWASP API Security Top 10
6. NIST SP 800-204 (Microservice Security)
7. Envoy Proxy Documentation
8. JWT Security Best Practices (RFC 8725)
9. OAuth 2.0 Security Best Practices
10. CORS Security. MDN