Protection

Client → CDN/WAF → API Gateway → Application → Database

Layer 1 — Edge (CDN / WAF):
  → DDoS protection (absorb volumetric attacks)
  → WAF rules (block SQL injection, XSS patterns)
  → IP filtering (block known malicious IPs)
  → Rate limiting (per IP, per region)

Layer 2 — API Gateway:
  → Authentication (validate JWT / API key)
  → Authorization (check permissions for this endpoint)
  → Request validation (schema, size limits, content type)
  → Rate limiting (per user / per API key)

Layer 3 — Application:
  → Input sanitization (prevent injection attacks)
  → Business logic authorization (can this user access this resource?)
  → Audit logging (who did what, when)
  → CORS enforcement

Layer 4 — Database / Storage:
  → Encryption at rest (AES-256)
  → Access control (least privilege, no public access)
  → Encrypted backups
  → Network isolation (private subnet, no public IP)

Incoming request:
  POST /api/orders
  Authorization: Bearer eyJhbGciOiJSUzI1NiIs...
  Content-Type: application/json
  Body: { "product_id": 42, "quantity": 2 }

Gateway checks (in order):

1. AUTHENTICATION — Is the token valid?
   → Decode JWT → verify signature → check expiration
   → Invalid? → 401 Unauthorized (request rejected)

2. RATE LIMITING — Is this user within their quota?
   → Check: user-42 has made 95/100 requests this minute
   → Over limit? → 429 Too Many Requests
   → Under limit? → increment counter, proceed

3. REQUEST VALIDATION — Is the request well-formed?
   → Content-Type must be application/json
   → Body must match schema (product_id: integer, quantity: integer > 0)
   → Body size < 1 MB
   → Invalid? → 400 Bad Request

4. AUTHORIZATION — Does this user have permission?
   → User role: "customer" → can access POST /api/orders ✅
   → User role: "customer" → cannot access DELETE /api/admin/* ❌ → 403

5. ROUTING — Forward to the correct backend service
   → /api/orders → Order Service
   → /api/products → Product Service

All checks pass → forward request to backend service
Any check fails → return error, backend never sees the request

Normal traffic: 10,000 requests/sec → servers handle it fine

DDoS attack: 10,000,000 requests/sec from 50,000 IPs
  → Servers overwhelmed → CPU 100% → memory exhausted
  → Legitimate users get timeouts → "site is down"
  → Attack costs the attacker $50/hour (botnet rental)
  → Downtime costs you $50,000/hour (lost revenue + reputation)

Defense layers:

Layer 1 — CDN / Edge (Cloudflare, AWS Shield):
  → Absorbs volumetric attacks at the edge (Tbps capacity)
  → Filters known bot traffic patterns
  → Geo-blocking (block traffic from regions you don't serve)
  → 95% of attack traffic never reaches your servers

Layer 2 — API Gateway:
  → Rate limiting per IP: 100 requests/minute
  → Rate limiting per user: 1000 requests/minute
  → Block IPs that exceed thresholds
  → Challenge suspicious traffic (CAPTCHA)

Layer 3 — Application:
  → Connection limits per client
  → Request timeout (kill slow requests)
  → Circuit breaker (stop calling overwhelmed downstream services)
  → Graceful degradation (serve cached content when under attack)

Without encryption (HTTP):
  Client → "password=hunter2" → [anyone on the network can read this] → Server
  → WiFi sniffing, ISP monitoring, man-in-the-middle attacks

With encryption (HTTPS / TLS):
  Client → [encrypted blob] → [unreadable to anyone in between] → Server
  → Only the client and server can read the data

What TLS protects:
  ✅ Confidentiality — data is encrypted (can't be read)
  ✅ Integrity — data can't be modified in transit
  ✅ Authentication — you're talking to the real server (certificate)

Where to use TLS:
  → Client ↔ Server: HTTPS (mandatory for any public API)
  → Service ↔ Service: mTLS (mutual TLS, both sides verify)
  → Service ↔ Database: TLS connection (encrypt DB traffic)
  → Everywhere. There is no reason to use unencrypted connections.

Without encryption at rest:
  Database disk is stolen / accessed by unauthorized person
  → All data is readable in plain text
  → Passwords, credit cards, personal info — all exposed

With encryption at rest:
  Database disk is stolen / accessed
  → Data is encrypted with AES-256
  → Without the encryption key, data is unreadable gibberish

What to encrypt:
  ✅ Database storage (PostgreSQL: pgcrypto, RDS encryption)
  ✅ Object storage (S3 server-side encryption: SSE-S3, SSE-KMS)
  ✅ Backups (encrypted backups — if backup is stolen, data is safe)
  ✅ Sensitive fields (credit card numbers, SSN — application-level encryption)

Key management:
  → Keys stored in a Key Management Service (AWS KMS, HashiCorp Vault)
  → Keys rotated periodically (every 90 days)
  → Access to keys is audited and restricted
  → NEVER store encryption keys in code or config files

Client (HTTPS)
  │
  ▼
CDN / WAF (Cloudflare)
  → DDoS absorption
  → WAF rules (OWASP Top 10)
  → Bot detection
  │
  ▼
API Gateway (Kong / AWS API Gateway)
  → JWT validation
  → Rate limiting (per user, per IP)
  → Request schema validation
  │
  ▼
Application (Node.js / Go)
  → Authorization (ownership checks)
  → Input sanitization
  → Audit logging
  → CORS enforcement
  │
  ▼ (TLS)
Database (PostgreSQL, private subnet)
  → Encrypted at rest (AES-256)
  → Sensitive fields: app-level encryption
  → Access: application servers only
  → Backups: encrypted with KMS