Analyst Field Guide · HTTP & the Application Layer
Once the packet has been routed, switched, and decrypted, something has to actually say what it wants. That something is usually HTTP — the request/response language that carries nearly all of the web and most modern APIs. This guide is how it works, how to read it when it breaks, and the large attack surface that lives up here where the applications are.
HTTP is where applications and people meet the network. Everything the Networking and Wi-Fi guides describe — framing, addressing, routing, the tunnel — exists to carry bytes so that, at the top, a client can send a request ("GET me this page") and a server can send a response ("200 OK, here it is"). It's a deliberately simple, stateless, text-legible protocol, which is exactly why it's easy to read, easy to build on, and a very large place for things to go wrong.
HTTP rides at the top of the stack. Below it, TLS encrypts the channel, TCP (or QUIC) moves the bytes reliably, IP routes them, and the link layer carries them across each hop. HTTP itself doesn't care how the bytes arrive — which is why the same requests work identically over HTTP/1.1, /2, or /3.
404 or 500 is HTTP itself.Because HTTP is stateless, each request stands alone — the server remembers nothing between them unless something in the request carries the context (a cookie, a token, a session id). That single design choice explains cookies, tokens, and much of the attack surface later in this guide.
Both directions share the same shape: a start line, some headers, a blank line, and an optional body. Learn to read that shape and most of HTTP is legible.
GET (fetch), POST (submit/create), PUT (replace), PATCH (modify), DELETE (remove), HEAD (headers only), OPTIONS (capabilities). The semantics are version-independent — RFC 9110 defines them once for HTTP/1.1, /2, and /3 alike.Status codes come in five classes, and the class is the fastest triage signal you have: 1xx informational, 2xx success, 3xx redirection, 4xx the request/client was wrong, 5xx the server failed. That 4xx-vs-5xx split is the single most useful triage signal in HTTP, and §9 leans on it heavily.
The model above (client asks, server answers, done) doesn't fit real-time apps — chat, live dashboards, collaborative editing. Two patterns escape it. WebSockets begin as an ordinary HTTP request carrying Upgrade: websocket; the server answers 101 Switching Protocols and the connection becomes a persistent, bidirectional channel (ws://, or wss:// over TLS). After that upgrade it is no longer HTTP — different framing — so normal HTTP logging, proxies, and request-based tools see the initial upgrade but not the messages that follow, which is a real monitoring blind spot. Server-Sent Events (SSE) stay within HTTP: the server holds one response open and streams text/event-stream events one-way, server to client, with reconnection built in — simpler than WebSockets when you only need push. The failure mode that reaches the help desk: long-lived connections die at idle timeouts on proxies and load balancers ("it drops every 60 seconds"), so those intermediaries must be configured for persistent connections. And like any TLS traffic, wss:// is opaque on the wire — you'll see the connection, not the content.
Three versions coexist on today's web. They share identical semantics (RFC 9110) — the same methods, status codes, and headers — and differ only in how those are put on the wire and what transport carries them.
HTTPS is just HTTP carried inside a TLS session. TLS (the current version is 1.3, RFC 8446) gives the connection three properties against a network attacker: confidentiality (eavesdroppers see ciphertext), integrity (tampering is detected), and server authentication (the certificate proves you reached the host named in it — validated against a trusted CA, with the requested name carried in the TLS SNI field).
This is the single most misunderstood point at this layer. A valid certificate means the connection to that hostname is encrypted and unmodified. It says nothing about whether the site is honest, the server is uncompromised, or the application logic is sound. A phishing page served from secure-login-yourbank.example can hold a perfectly valid certificate and a padlock. TLS defends against interception and tampering in transit; it leaves phishing, a breached server, malicious content, and every application-layer flaw in §7 completely untouched. HSTS (RFC 6797) hardens one specific gap — it tells browsers to refuse plaintext HTTP to that host on future visits, defending against downgrade/strip attacks, with the residual that the very first visit is unprotected unless the host is preloaded.
So "is it HTTPS?" and "is it safe to trust?" are different questions. The first is about the pipe; the second is about everything this guide covers from §5 onward — and ties directly to the Identity guide (who is the user) and the VPN guide (the gateway is still attack surface).
Because HTTP forgets everything between requests, "being logged in" has to be re-proven on every single request. The mechanisms differ, but all of them come down to the client re-presenting a secret the server issued earlier.
Set-Cookie; the browser returns it on subsequent requests. The classic session mechanism.Authorization header; often used for APIs and SPAs. Anyone holding the token can use it, so its storage and transport are the security question.Whichever is used, the secret is a credential in flight — and cookie attributes are the difference between "hard to steal" and "trivially stolen":
| Cookie attribute | What it does · the threat it addresses |
|---|---|
Secure | Sent only over HTTPS — keeps the cookie off plaintext HTTP where it could be sniffed. Residual: doesn't help if the site is served over HTTP in the first place. |
HttpOnly | Not readable by JavaScript — limits token theft via cross-site scripting (§7). Residual: the cookie is still sent on every request, so it doesn't stop CSRF. |
SameSite (Lax/Strict/None) | Limits whether the cookie rides on cross-site requests — mitigates CSRF. Residual: not a complete CSRF defense on its own; pair with anti-CSRF tokens for state-changing actions. |
A session cookie or bearer token is the authenticated identity for the life of the request. That's why theft of one (via XSS, an open redirect, a leaky log, or an intercepted plaintext hop) is equivalent to a password compromise — and why the flags above, short lifetimes, and TLS everywhere are the controls that constrain the damage rather than eliminate it.
Very little traffic reaches the origin server directly. Content delivery networks, reverse proxies, load balancers, caches, and web application firewalls sit in front — which is good for performance and defense, and complicates the simple question "who am I actually talking to?"
For an analyst this reframes several everyday tasks: rate-limiting or blocking by IP, reading access logs, and attributing a request all depend on knowing your proxy chain and which forwarded-header your edge actually sets and sanitizes.
Once you're above the packet, the attacks are about logic and input, not routing. The industry's shared reference for this is the OWASP Top 10 — the current edition is OWASP Top 10:2025 (the eighth, released late 2025; verify it's still current before citing, as it revises every few years). It's an awareness ranking of risk categories, not an exhaustive list, but it's the right vocabulary and priority order to start from.
| 2025 category | The risk, in one line |
|---|---|
| A01 Broken Access Control | Users reach data or actions outside their permissions. Now also absorbs SSRF (server tricked into making requests). Still #1. |
| A02 Security Misconfiguration | Insecure defaults, open storage, unnecessary services, verbose error pages. Rose from #5 to #2. |
| A03 Software Supply Chain Failures | Compromise via dependencies, build systems, or distribution — broader than "known-vulnerable components." |
| A04 Cryptographic Failures | Weak or missing crypto exposing data in transit or at rest. |
| A05 Injection | Untrusted input interpreted as code or query — SQL injection, command injection, and cross-site scripting (XSS) live here. |
| A06 Insecure Design | The flaw is in the design itself; no amount of clean implementation fixes a missing control. |
| A07 Authentication Failures | Weak, guessable, or bypassable authentication (renamed from "Identification and Authentication Failures"). |
| A08 Software & Data Integrity Failures | Trusting unverified updates, plugins, or deserialized data. |
| A09 Security Logging & Alerting Failures | Can't detect or respond because nothing was logged or nothing alerted (renamed to stress alerting). |
| A10 Mishandling of Exceptional Conditions | New for 2025: fail-open logic, bad error handling, leaking internals in stack traces. |
Nearly all of these reduce to trusting input or state that arrived over an untrusted channel. HTTP hands the client full control over the URL, every header, every cookie, and the body — so anything the server assumes about them can be violated. "The dropdown only offered three values" is not a control; the attacker sends a fourth directly. Treat every field of every request as attacker-controlled until validated. Each category names a real threat; none of the defenses below make an application "secure" in the abstract — they reduce specific risks and leave others (see §8).
A handful of response headers and server-side habits carry most of the layer's defensive weight. Each addresses a named threat and leaves a named residual — state both when you evaluate one.
| Control | Threat addressed · residual |
|---|---|
| HSTS (Strict-Transport-Security) | Forces HTTPS on future visits → defeats downgrade/SSL-strip. Residual: first visit is unprotected unless preloaded; nothing about site honesty. |
| CSP (Content-Security-Policy) | Restricts where scripts/content may load from → limits the impact of XSS. Residual: complex, easy to misconfigure into uselessness; not a substitute for output encoding. |
| Cookie flags | Secure/HttpOnly/SameSite → constrain sniffing, JS theft, and CSRF respectively (§5). Residual: each covers one vector only. |
| CORS | Controls which origins' JavaScript may read a cross-origin response. Residual — critical: CORS is a browser policy, not a server-side access control. It does not protect data; the server must still authorize every request. |
| Input validation / output encoding | Reject or neutralize hostile input → the root defense against injection/XSS. Residual: must be applied at every sink; one missed spot is the bug. |
| TLS configuration | Modern versions/ciphers → passive decryption & downgrade resistance (§4). Residual: protects the channel, not the server or content. |
The recurring trap is treating a browser-enforced control as a server-side guarantee. CORS, client-side validation, and a disabled UI button all live in the browser, and the browser is the attacker's tool. Every one of them must be re-checked server-side.
The status-code class tells you which side to look at first: a 4xx points at the request (yours/the client's), a 5xx points at the server. That one distinction resolves a surprising share of tickets before you touch anything.
| Symptom | Read it as |
|---|---|
401 / 403 | Authentication vs. authorization: 401 = not (or wrongly) authenticated; 403 = authenticated but not allowed. Mirrors the Identity guide's authN-vs-authZ split. |
404 vs 5xx | 404 the resource/route is wrong (client side); 500/502/503/504 the server, an upstream, or a gateway failed or timed out (server side). |
| Certificate / TLS error | Layer 4 problem, not HTTP: expired/mismatched/untrusted cert, wrong SNI, or a TLS-version/cipher mismatch. The request never became HTTP. |
| Redirect loop / too many redirects | Conflicting 3xx rules (often HTTP↔HTTPS or www↔apex misconfigured), frequently between a CDN and the origin. |
| "Mixed content" blocked | An HTTPS page pulling sub-resources over HTTP; the browser blocks them. A page-config issue, not a server error. |
| CORS error in the console | The browser refused to let JS read a cross-origin response. It's a browser policy result — the request may have succeeded server-side (§8). |
| Stale / wrong content | Caching: a CDN or browser cache is serving an old representation. Check Cache-Control and try a cache-busting fetch. |
Tools that make HTTP legible: curl -v (or -I for headers only) to see the raw exchange, browser DevTools → Network for the full request/response including timing and headers, and an intercepting proxy for inspecting or replaying requests. Reading the actual headers beats guessing almost every time.
| Belief | Reality |
|---|---|
| "There's a padlock, so the site is safe" | The padlock means the channel to that hostname is encrypted and authenticated. A phishing site can have a valid certificate. HTTPS ≠ trustworthy (§4). |
| "HTTPS means end-to-end encryption" | Through a CDN or proxy, TLS terminates at the edge and re-encrypts to the origin — hop-by-hop, not end-to-end (§6). |
| "GET is safe, so it can't do harm" | "Safe" means it shouldn't change state — but a badly designed app may act on a GET, and GET URLs land in logs, history, and referrers. |
| "The client validated it, so it's fine" | Client-side validation, disabled buttons, and CORS all run in the browser — the attacker's tool. Re-validate everything server-side (§8). |
| "CORS protects my API" | CORS governs whether a browser lets JS read a cross-origin response. It's not access control; the server must still authorize each request. |
| "A 200 means everything worked" | Only that HTTP succeeded. The body can still carry an application-level error, or exactly the data an attacker wanted. |
Request = method + path + version, headers, blank line, optional body. Response = version + status + reason, headers, body. Stateless: every request re-carries its own context. Semantics are identical across versions (RFC 9110).
1xx info · 2xx success · 3xx redirect · 4xx the request/client · 5xx the server. Triage: 401 = authn, 403 = authz, 404 = wrong route, 502/503/504 = upstream/gateway.
1.1 (text/TCP, serialized) · 2 (binary/TCP, multiplexed) · 3 (QUIC/UDP 443, TLS 1.3, independent streams). HTTP/3 won't show up in a TCP-only capture filter.
HTTPS authenticates the channel, not the site — a phishing page can have a valid cert. Through a proxy, TLS is hop-by-hop. Treat every header/cookie/param as attacker-controlled; re-validate server-side. CORS is not access control.
Broken access control (incl. SSRF) · misconfiguration · supply chain · crypto failures · injection/XSS · insecure design · authentication failures · integrity failures · logging/alerting gaps · mishandled error conditions. Verify the edition is current before citing.
Standards current as of mid-2026 and flagged to verify against the primary source. HTTP was reorganized in 2022: RFC 9110 (HTTP Semantics, an Internet Standard, STD 97) defines methods, status codes, and headers for all versions; RFC 9111 covers caching; RFC 9112 is HTTP/1.1; RFC 9113 is HTTP/2 (obsoleting RFC 7540); RFC 9114 is HTTP/3 over QUIC (RFC 9000), which incorporates TLS 1.3. The current TLS version is 1.3 (RFC 8446); HSTS is RFC 6797 — confirm these RFC numbers and any port assignments (HTTP 80, HTTPS 443 over TCP for HTTP/1.1 and /2, UDP 443 for HTTP/3) before relying on them. The OWASP Top 10:2025 is the current edition as of mid-2026 (verify it hasn't been superseded before citing category numbers); it is an awareness ranking of risk categories, not an exhaustive standard. No configuration or header makes an application "secure" in the abstract: each control named here addresses a specific threat (interception, downgrade, XSS impact, CSRF, injection) and leaves specific residuals (phishing, a compromised server, application logic flaws, anything re-validated only in the browser). Companion to Networking ("Follow the Packet" — the transport beneath HTTP), Wi-Fi ("Working the Air" — the first hop), VPN & IPsec (the tunnel, and the gateway as attack surface), Identity & Authentication (who the user is; the 401-vs-403 distinction), and Incident Response (reading HTTP logs and evidence during an incident).