Gatekeeper Pattern
A dedicated host that validates and sanitizes requests before forwarding to backend services: defense in depth, DMZ architecture, and request filtering.
The Gatekeeper Pattern
The Gatekeeper pattern places a dedicated, hardened host between clients and backend services. This host's sole responsibility is to validate, authenticate, and sanitize every incoming request before forwarding it to the actual application servers. Backend services operate in a protected network zone and are never directly reachable by the outside world.
This is a defense-in-depth approach: even if an attacker finds a zero-day in the application logic, they must also defeat the gatekeeper — which runs minimal code, has a tiny attack surface, and is configured to reject anything malformed. Think of it as the bouncer at a club: no one gets past without ID, regardless of how well-dressed they are.
Architecture Overview
What the Gatekeeper Does
- Authentication & authorization: Validates tokens (JWT, API keys, OAuth), rejects unauthenticated requests before they reach backend services.
- Input validation & sanitization: Checks content-type, payload size limits, schema conformance, and strips dangerous characters to prevent injection attacks.
- Rate limiting & throttling: Enforces per-client or per-IP request limits, dropping excess requests before they consume backend resources.
- TLS termination: Handles HTTPS, offloading cryptographic overhead from backend services.
- Request routing: Forwards validated requests to the correct backend service based on path, host, or headers.
- Audit logging: Records all requests (including rejected ones) for security forensics.
Gatekeeper vs API Gateway
The Gatekeeper pattern is frequently implemented as an API Gateway (e.g., AWS API Gateway, Kong, Nginx, Envoy). The distinction lies in emphasis: an API gateway focuses on routing and composition, while the gatekeeper pattern foregrounds security validation as the primary concern. In practice, a well-configured API gateway enforces gatekeeper responsibilities.
| Aspect | API Gateway | Strict Gatekeeper |
|---|---|---|
| Primary focus | Routing, aggregation, transformation | Security validation and rejection |
| Trust model | Partially trusted requests may pass through | Zero-trust: reject anything not explicitly allowed |
| Deployment | Shared infrastructure | Often a dedicated, hardened host |
| Common tools | AWS API Gateway, Kong, Nginx | WAF + API Gateway, custom proxy |
Sequence: Request Validation Flow
Never Trust Internal Caller Headers from the Outside
A common mistake is allowing clients to set internal headers like `X-User-Id` or `X-Roles` directly. The Gatekeeper must strip any client-supplied trusted headers before injecting its own validated values. Otherwise an attacker can simply send `X-User-Id: admin` and bypass authorization entirely.
Trusted Subsystem Model
Once a request passes the Gatekeeper, backend services operate in a trusted subsystem model: they trust the Gatekeeper has already performed authentication and authorization, and they consume the injected identity headers (`X-User-Id`, `X-Roles`, `X-Tenant-Id`) directly without re-validating. This simplifies backend services and reduces latency. However, it requires that backend services are only reachable from the Gatekeeper — never from the public internet.
Defense in Depth
The Gatekeeper pattern pairs well with a Web Application Firewall (WAF) sitting in front of it, and a service mesh (like Istio) enforcing mTLS between backend services. Each layer adds an independent security control, so a single compromise does not grant full access.
Interview Tip
Interviewers often ask how you'd secure an API surface. Mentioning the Gatekeeper pattern shows you think in layers. Key points to hit: (1) the Gatekeeper has a minimal attack surface and runs hardened code only, (2) backend services have no public network exposure, (3) the trusted subsystem model lets backends avoid re-validating tokens — but only because the gatekeeper guarantees the network path. This is the same reason AWS API Gateway + IAM policies are more secure than just validating tokens in each Lambda.