# Production Security Checklist
The gateway is designed with a "Zero Trust" security philosophy, minimizing the attack surface by default. However, a secure deployment requires coordination between the gateway's internal features and your infrastructure.
## Gateway Security Features (Built-in)
When correctly configured, the gateway provides **Enterprise-Grade** security covering the following layers:
### 1. Zero-Trust Access Layer
- **Query Whitelisting**: With `WhitelistMode::Enforce`, the gateway rejects all arbitrary queries. This neutralizes 99% of GraphQL-specific attacks (introspection abuse, deep nesting, resource exhaustion) effectively treating GraphQL as a secured set of RPCs.
- **Introspection Disabled**: Schema exploration is blocked in production.
### 2. Browser Security Layer
- **HSTS**: `Strict-Transport-Security` enforces HTTPS usage.
- **CSP**: `Content-Security-Policy` limits script sources using 'self'.
- **CORS**: Strict Cross-Origin Resource Sharing controls.
- **XSS Protection**: Headers to prevent cross-site scripting and sniffing.
### 3. Infrastructure Protection Layer
- **DoS Protection**: Lock poisoning prevention (using `parking_lot`) and safe error handling (no stack leaks).
- **Rate Limiting**: Token-bucket based limiting with burst control.
- **IP Protection**: Strict IP header validation (preventing `X-Forwarded-For` spoofing).
## Operational Responsibilities (Ops)
While the gateway code is secure, your deployment environment must handle the following external responsibilities:
### ✅ TLS / SSL Termination
The gateway speaks plain HTTP. You **must** run it behind a reverse proxy (e.g., Nginx, Envoy, AWS ALB, Cloudflare) that handles:
- **HTTPS Termination**: Manage certificates and TLS versions (TLS 1.2/1.3 recommended).
- **Force Redirects**: Redirect all HTTP traffic to HTTPS.
### ✅ Secrets Management
Never hardcode sensitive credentials. Use environment variables or a secrets manager (Vault, AWS Secrets Manager, Kubernetes Secrets) for:
- `REDIS_URL`
- API Keys
- Database Credentials
- Private Keys (if using JWT signing)
### ✅ Authentication & Authorization
The gateway validates the **presence** of auth headers (via middleware), but your logic must define the **validity**:
- **JWT Verification**: Ensure your `EnhancedAuthMiddleware` is configured with the correct public keys/secrets.
- **Role Limits**: Verify that identified users have permission to execute specific operations.
### ✅ Network Segmentation
- **Internal gRPC**: The gRPC backend services should typically be isolated in a private network, accessible only by the gateway.
- **Redis Access**: Restrict Redis access to only the gateway instances.
## Verification
Before deploying to production, run the included comprehensive security suite:
```bash
# Run the 60+ point security audit script
./test_security.sh
```
A passing suite confirms that all built-in security layers are active and functioning correctly.