Security Patterns

Architecture Overview

Security is applied at three layers:

1. Edge/Proxy Layer    ← Rate limiting, CSP, security headers, IP deny
2. Application Layer   ← Auth rate limit, session validation, input sanitization
3. Infrastructure Layer ← Auto-protection, firewall, DDoS mitigation

Layer 1: Edge/Proxy

Rate Limiting

Applied before requests reach application code.

• Algorithm: Fixed window (cheaper) or sliding window (stricter)
• Identifier: Client IP (x-forwarded-for → x-real-ip)
• Tiers: Different limits per route group (auth, api, public)

Request → match route tier → ratelimit.limit(ip) → pass or 429
                              ↓ (timeout → allow on failure)
                        Application handler

Content Security Policy (CSP)

Dynamic CSP built from environment variables:

Security Headers

Layer 2: Application

• Auth rate limits (e.g., 10 req/60s on login endpoints)
• Session validation on every protected action
• Input sanitization (XSS prevention)
• CSRF tokens on mutations

Layer 3: Infrastructure

• Auto IP deny list from open-source threat feeds
• DDoS protection at cloud provider level
• Database connection limits and query timeouts

Graceful Degradation

If the rate limiting service is unreachable:

1. Timeout (e.g., 1s) triggers catch clause
2. Request is allowed through (fail open)
3. Security headers still applied
4. Next request retries — resumes when service is back

Quick Reference

# Test security headers
curl -I https://example.com | grep -i "x-\|strict-\|referrer-\|permissions-"

# Test rate limiting
for i in $(seq 1 20); do curl -s -o /dev/null -w "%{http_code}\n" https://example.com/api/endpoint; done

References

• Security Patterns
• Rate Limiting
• Request Headers
• Environment Variables — Secret generation, rotation, .env hierarchy