Security Architecture

Defense in depth for a multi-region cloud application

Philosophy

Security is not a feature you add at the end—it’s a property that emerges from careful design at every layer. DineHub follows defense in depth: multiple independent security mechanisms, each sufficient on its own, so that if one fails, others still protect the system.

We assume attackers will eventually breach some defenses. The goal is to make that breach useless—to limit what they can access and detect the intrusion quickly.

Security Layers

┌──────────────────────────────────────────────────────────────┐
│ Layer 7: Application Security                                │
│ • Authentication (JWT)                                       │
│ • Authorization (RBAC)                                       │
│ • Input validation                                           │
│ • Output encoding                                            │
├──────────────────────────────────────────────────────────────┤
│ Layer 6: API Security                                        │
│ • HTTPS/TLS                                                  │
│ • Rate limiting                                              │
│ • CORS policies                                              │
│ • API versioning                                             │
├──────────────────────────────────────────────────────────────┤
│ Layer 5: Network Security                                    │
│ • Zero-trust mesh (Tailscale)                                │
│ • Firewall rules                                             │
│ • Private IPs only                                           │
│ • No lateral movement                                        │
├──────────────────────────────────────────────────────────────┤
│ Layer 4: Host Security                                       │
│ • Immutable infrastructure                                   │
│ • Minimal attack surface                                     │
│ • Automatic updates                                          │
│ • Read-only filesystems                                      │
├──────────────────────────────────────────────────────────────┤
│ Layer 3: Secrets Management                                  │
│ • Encryption at rest                                         │
│ • No secrets in code                                         │
│ • Rotation policies                                          │
│ • Audit logging                                              │
├──────────────────────────────────────────────────────────────┤
│ Layer 2: Access Control                                      │
│ • Least privilege                                            │
│ • Multi-factor authentication                                │
│ • Role-based permissions                                     │
│ • Session management                                         │
├──────────────────────────────────────────────────────────────┤
│ Layer 1: Physical Security                                   │
│ • Cloud provider guarantees                                  │
│ • Multi-region distribution                                  │
│ • Encrypted storage                                          │
└ ─────────────────────────────────────────────────────────────┘

Application Security

Authentication

We use JWT (JSON Web Tokens) for authentication:

Stateless: No server-side session storage
Self-contained: Token carries user identity
Expirable: Short-lived tokens (24 hours)
Revocable: Token blacklist for logout

JWTs are signed with a server-side secret. Attackers can’t forge tokens without the secret, and expired tokens are automatically rejected.

Authorization

Role-Based Access Control (RBAC) defines what users can do:

USER: Browse restaurants, place orders, manage own orders
RESTAURANT_OWNER: All USER permissions + manage owned restaurants + view restaurant orders
ADMIN: Full system access

Permissions are enforced at the API endpoint level. Even if a user knows an endpoint exists, they can’t access resources they don’t own.

Input Validation

All user input is treated as untrusted:

Type validation: DTOs with strict typing
Range checks: Numeric values within expected ranges
Length limits: Prevent buffer overflow attempts
Format validation: Emails, UUIDs match expected patterns
Sanitization: Remove or escape dangerous characters

Validation happens at the API boundary, before data reaches business logic.

Network Security

Zero-Trust Architecture

We don’t trust the network—even our internal network:

Encryption everywhere: All traffic encrypted via WireGuard (Tailscale)
Mutual authentication: Both sides verify each other’s identity
No implicit trust: Every connection requires explicit authorization
Micro-segmentation: Services can only talk to required dependencies

Network Segmentation

Infrastructure divided into security zones:

Public zone (ingress only):

Exposed to internet
Minimal attack surface (nginx only)
All traffic forwarded to private zone

Private zone (application servers):

No public IPs
Access only via Tailscale
Can only initiate connections to data zone

Data zone (databases):

No external access except from application servers
Additional PostgreSQL authentication
Encrypted storage volumes

This segmentation means compromising one zone doesn’t automatically grant access to others.

Firewall Strategy

Traditional firewalls rely on IP whitelisting. We use identity-based access control:

Single port: Tailscale uses one UDP port for all connectivity
No application ports exposed: Database and application ports not visible to network
Cryptographic identity: Nodes authenticated by certificates, not IP addresses