Test both the API gateway and the microservices behind it when either layer can make or inherit a security decision. A gateway-only assessment validates the front door but can miss direct reachability, inconsistent service authorization, trusted headers and alternate protocols. Testing every service blindly wastes effort. The right scope follows decisions and bypass paths.
Start with the policy ownership map
For each API capability, record what the gateway enforces and what the service enforces independently. Cover authentication, token validation, audience, tenant binding, object authorization, schema validation, rate limits and audit logs. Mark controls that exist only at the gateway, only in the service, or in both with deliberately different responsibilities.
Duplication is not automatically defence in depth. Two partial implementations may create gaps, while inconsistent parsing can let a request be accepted differently at each layer. The assessment must test the composed behaviour.
Inventory every path to each service
- Public gateway hostname and versioned routes.
- Internal load balancers, ingress controllers and service-mesh addresses.
- Legacy gateways, regional endpoints and migration routes.
- Direct container, node-port or cloud service exposure.
- Message queues, scheduled jobs and event consumers.
- Administrative, health, metrics and debugging interfaces.
Confirm routes with DNS, cloud inventory, gateway configuration and service ownership—not only documentation. A service considered internal may be reachable through peering, customer networks, CI runners or server-side request forgery.
Validate gateway authentication and token normalization
Test issuer, audience, signature algorithm, key rotation, expiry and token type. Determine which claims the gateway forwards and whether it removes client-supplied copies first. Challenge duplicate headers, case variants, encoded paths and conflicting host or forwarding metadata.
If the gateway creates a signed internal assertion, verify its audience, lifetime and binding to the intended downstream service. If it forwards ordinary headers, require the service to distinguish trusted gateway traffic from a direct caller.
Attempt direct-service access safely
- Establish the legitimate request through the gateway.
- Identify approved internal route or test harness.
- Repeat without gateway-added identity context.
- Supply forged or stale versions of trusted headers.
- Vary host, protocol, method and content type.
- Confirm the service denies the action or performs independent authorization.
Do not scan internal address space indiscriminately. Use an agreed service inventory and controlled source. The objective is to test the trust assumption, not broaden access beyond authorization.
Test object authorization in the owning service
The gateway can authorize a route or coarse scope, but the service usually owns object relationships and business state. Test cross-user, cross-tenant and role transitions at the service boundary. Confirm downstream calls preserve the original actor where policy depends on it rather than collapsing every request into a powerful service identity.
Challenge path and parser inconsistencies
- Encoded slashes, dot segments and repeated separators.
- Duplicate query parameters and headers.
- Method override and unexpected HTTP verbs.
- Conflicting content length or transfer semantics where safe.
- JSON duplicate keys, numeric coercion and alternate media types.
- Case sensitivity and version aliases.
A gateway may validate one normalized representation while a framework routes another. Test only non-disruptive variants under agreed conditions, and report which layer interpreted each request.
Exercise route and version drift
Compare current, deprecated and internal versions. Confirm retired routes are disabled at the gateway and service, and that a renamed route does not retain weaker authorization. Include shadow deployments, regional stacks and migration bridges because control parity often drifts during transition.
Evaluate service identity and east-west calls
Determine whether downstream services authenticate the caller workload, authorize its purpose and restrict token audience. A network location or mesh membership alone should not grant every internal capability. Test stolen-token blast radius with synthetic credentials or policy review rather than extracting live secrets.
- Token for service A is replayed to service B.
- Gateway identity is accepted on an internal-only administrative method.
- User context is lost and replaced by an overprivileged workload.
- Revoked service remains trusted until a long-lived credential expires.
Include asynchronous entry points
A queue or event bus is another gateway. Verify producer identity, message schema, tenant and actor context, consumer authorization, replay protection and dead-letter handling. A service secure over HTTP can still process a forged or stale event with elevated privilege.
Test rate limits where state is shared
Identify whether limits apply by IP, actor, token, tenant, route or business action, and whether direct service access bypasses them. Use conservative agreed volumes. For high-impact actions, confirm the service protects the invariant even if a gateway quota is misconfigured.
Correlate evidence across layers
Capture gateway request ID, service trace, identity claims, policy result and final data state. A 403 at the edge does not prove the service would refuse direct access; a 200 response does not prove the downstream mutation succeeded. End-to-end evidence is essential.
Choose depth by security decision
Test representative services that own distinct authorization models, data classifications and exposure paths. Expand when a shared pattern fails. Reduce duplicate checks when a centrally enforced control is technically verified and all bypass routes are closed, but still sample service-level fail-safe behaviour.
Remediate at the correct layer
Use the gateway for consistent edge concerns and services for resource-specific authorization and invariants. Authenticate east-west calls, remove spoofable identity headers, restrict direct routes and standardize parsing. Treat duplicated policy as code with ownership and tests, not undocumented coincidence.
Retest gateway, direct and chained paths
After remediation, repeat the edge request, direct-service hypothesis and a downstream call carrying user context. Verify old versions and alternate routes too. The fix is complete when every supported path reaches an equivalent security decision at the layer that owns it.
Use the OWASP Web Security Testing Guide for request and authorization techniques, then extend them across gateway normalization, direct reachability, service identities and asynchronous ingress.
The architecture decision
Do not choose gateway-only or every-service testing as a slogan. Map control ownership and all ingress paths, then test the gateway, the service that owns the resource, and any bypass or transformation between them. That approach finds architectural gaps without duplicating the entire assessment.
Ask WIMD to scope gateway and microservice testing around actual policy decisions, direct routes and downstream trust.