Security In Depth — HTTP Request Journey Map
April 5, 2025
When you click "Log in" in a web application, one thing doesn't happen. Dozens of things happen — in sequence, across different layers, on different servers, in different programming languages. Each of those layers is a separate point where something can go wrong. And each requires its own protection.
That's the essence of security in depth — not one big wall, but many independent lines of defense. If one fails, the next stops the attack. If someone bypasses CORS, they still run into server-side validation. If they manage to forge a token — they hit the permission check for the specific resource. Each layer has its job. Together they form a mesh that's hard to pass through unnoticed.
In this series, each post covers one stop on the HTTP request journey. Here's the complete map.
HTTP Request Journey Map
Before a request reaches the database and returns with a response, it must pass through a dozen layers.
Layer 0 — Dev Environment
Before you write a single line of code, you can already make a security mistake. A compromised development environment means a compromised production — because API keys, access tokens, and database passwords start their lives right here.
The most common mistakes are keys pasted directly into code (and pushed to GitHub), public repositories with configuration data, and missing two-factor authentication on developer accounts. One accidentally pushed .env is enough.
Details: Securing Your Development Environment
Layer 1 — Client / UI
The browser and mobile app are the first thing a user encounters — and the first layer an attacker can inspect. Every JavaScript file is public. Every network request visible in DevTools. Every form value can be changed before submission.
Frontend validation improves UX, but doesn't protect the application. Attackers don't use the form — they send requests directly to the API. That's why no security logic can live exclusively on the client side.
Important topics for this layer include CORS — the mechanism controlling which domains can query your API — and Content Security Policy, which limits which scripts can run on the page.
Details: Why Frontend Validation Is Never Enough | CORS Explained Simply
Layer 2 — DNS
DNS is the internet's "phone book" — it translates vibedefend.com into a server's IP address. Before your request reaches any code, it must go through DNS. And that's exactly where it can be intercepted.
DNS hijacking, cache poisoning, subdomain takeover — attacks on this layer are often invisible to the user, because the URL in the browser looks correct. DNSSEC and careful subdomain monitoring are the basic defenses.
Details: DNS Layer Security
Layer 3 — HTTPS / TLS
HTTPS encrypts the connection between client and server — no one in between can read or modify the data in transit. But the certificate itself is just the starting point.
Mixed content (HTTP assets on an HTTPS page), missing HSTS, outdated TLS versions (1.0, 1.1), certificates without automatic rotation — each of these issues can destroy what HTTPS is supposed to protect.
Details: When and What to Encrypt
Layer 4 — CDN / Reverse Proxy / WAF
Cloudflare, nginx, Caddy — this is the first server-side layer, seeing traffic before it reaches your code. A well-configured reverse proxy stops many attacks automatically: DDoS, port scanning, attempts to exploit known CVEs.
HTTP security headers — Strict-Transport-Security, X-Frame-Options, Content-Security-Policy, X-Content-Type-Options — are set here (or in application middleware). Most applications don't have them configured correctly.
Details: CDN and Security Headers
Layer 5 — API Gateway / Rate Limiting
Rate limiting restricts the number of requests from a single source in a given time window. Without it, your API is wide open to password brute force, credential stuffing, bulk data scraping, and simple server overload.
But rate limiting isn't just a security concern — it's also a cost issue. Uncontrolled traffic in a cloud environment translates directly to your bill.
Details: Why Rate Limiting Matters
Layer 6 — Authentication / Authorization
Two separate questions, often confused as one.
Authentication: Who are you? The user proves their identity — logging in with a password, token, fingerprint. Weak passwords, missing 2FA, broken password reset mechanisms — that's this layer.
Authorization: What can you do? Once we know who is sending the request, we check whether they have the right to the requested operation. Missing this check is IDOR (Insecure Direct Object Reference) — one of the most common API vulnerabilities.
Details: Basic User Authentication Strategies | Authentication vs. Authorization | RBAC for Beginners | Authentication Tokens and API Keys
Layer 7 — Business Logic / Validation
Input validation is essential, but it's not enough to check whether the "email" field contains @. Contextual validation asks: does this email belong to this user? Is this operation permitted in this application state? Does an order of this value make sense?
Mass assignment is a classic mistake at this layer: a framework automatically maps fields from the request to the data model, and among them lands isAdmin: true.
Details: Input Validation Basics | Why Frontend Validation Is Never Enough
Layer 8 — Database
Data eventually reaches the database — and that's where it can be stolen, modified, or deleted. SQL injection is still in the OWASP Top 10 despite being over 25 years old. ORMs help, but don't eliminate the problem entirely.
The database account your application uses should have minimal permissions — only as much as needed. Encryption at rest, secure connection strings, and regular password rotation aren't optional — they're obligations.
Details: Securing Your Database
Layer 9 — File System / Storage
File upload is one of the most dangerous features in a web application. The user sends a file — and you have to decide what to do with it, not really knowing what's inside.
The MIME type in the request header is a lie. The file extension is a lie. The only thing you can trust is your own analysis of the content. Files should never land in the web root, and access to private resources should go through signed URLs.
Details: File Upload Security
Layer 10 — Error Handling / Response
Error messages love to help with debugging — and they love helping attackers just as much. Stack traces with database table names, messages saying "no user with this email" (hinting which emails exist), headers revealing the server version — all of this is information leakage.
HTTP 401 and 403 are not the same thing. Returning the wrong status code is a subtle but real security issue.
Details: Error Handling and Information Leakage
Layer 11 — Monitoring / Logging
An attack that leaves no traces in logs is one you might miss for weeks. A good logging strategy isn't just "record everything" — it's recording the right things in the right way, without storing sensitive data (GDPR has things to say here).
Failed logins, unexpected spikes in request count, attempts to access out-of-scope resources — these are signals that should trigger alerts.
Layer 12 — Backup / Recovery
The last line of defense. When everything else fails — do you have a plan? A backup without a test isn't a backup, it's hope. An incident response plan written during an incident isn't a plan, it's chaos.
Details: Backups and Recovery
Why Every Layer Matters
Imagine an application with perfect HTTPS but no server-side validation. Or great authorization, but SQL injection in queries. Or an excellent firewall, but passwords stored in plaintext.
Security in depth isn't about making every layer perfect. It's about ensuring that the failure of one layer doesn't mean the compromise of the whole. Each barrier slows an attacker down and gives you time — time to detect, time to respond, time to fix.
Start with what matters most: what threatens your users. Authentication, data validation, HTTPS — don't launch without these. The rest you can add gradually as the application grows.
Security isn't a project to complete — it's a practice you develop alongside your code.
Sources: