HTTP/HTTPS Deep Dive

HTTP/1.1 is text-based and largely one-request-per-connection — even with keep-alive, responses come back in order, so a slow response blocks the ones behind it (head-of-line blocking). HTTP/2 is binary-framed and multiplexes many concurrent requests over a single TCP connection with header compression, removing HTTP-layer head-of-line blocking — but because it's still on TCP, a lost packet stalls all streams at the transport layer. HTTP/3 moves onto QUIC over UDP, which makes streams truly independent so packet loss only affects the one stream, integrates TLS 1.3 (always encrypted), and uses connection IDs that survive IP changes for seamless mobile handoffs. The arc is fewer round-trips and less blocking at each step.

HTTPS is HTTP over TLS, giving three things: confidentiality so an on-path eavesdropper can't read the content, integrity so they can't tamper without detection, and authenticity so the client verifies the server's identity via its CA-signed certificate. What it does not hide: the server's IP address, the hostname in the TLS SNI field which is sent in plaintext unless Encrypted Client Hello is used, the DNS lookup unless you use DoH/DoT, and traffic-analysis metadata like packet sizes and timing. So HTTPS protects the content of the conversation, but an observer still learns who you're talking to and roughly how much.

The same-origin policy stops JavaScript from reading responses from a different origin unless that origin opts in via CORS. For "simple" requests — GET/HEAD/POST with safe content types and no custom headers — the browser sends the request with an Origin header and only exposes the response to JS if the server returns a matching Access-Control-Allow-Origin. For anything else — a custom header, a DELETE, a JSON content type — the browser first sends a preflight OPTIONS request asking "can I send this method with these headers from this origin?", and only sends the real request if the server's Access-Control-Allow-* response permits it. The key point is CORS relaxes the same-origin policy under server control; it isn't a server-side access control itself.

SameSite is a cookie attribute controlling whether the browser attaches the cookie to cross-site requests. With Strict, the cookie is only sent when the request originates from the same site, so a request triggered from an attacker's page — the essence of CSRF — won't carry the victim's session cookie and the forged action fails. It cuts CSRF at the root because CSRF depends on the browser auto-attaching cookies to cross-site requests. The trade-off is that Strict also withholds the cookie on legitimate inbound navigation, like following a link from an email, so Lax is the common default — it sends the cookie on top-level GET navigations but not on cross-site sub-resource requests or form POSTs — usually paired with CSRF tokens for state-changing actions.

HSTS is a response header that tells the browser to only ever connect to this domain over HTTPS for the max-age duration, which defeats SSL-strip downgrade attacks and accidental HTTP requests. The catch is it's effectively a one-way commitment with a long memory: once a browser sees it, it refuses plain HTTP for that whole duration, even if you change your mind. So if you set a long max-age, or add includeSubDomains, before HTTPS is fully working everywhere — including every subdomain — you can lock users out with no fast undo. The safe rollout is a short max-age first, verify everything works, then raise it; and preload, which hard-codes the policy into browsers, is even more permanent and should be a deliberate final step.

Strict-Transport-Security to force HTTPS, rolled out carefully. A strong Content-Security-Policy as the main XSS backstop — ideally nonce-based with no unsafe-inline — started in report-only mode to find breakage. X-Content-Type-Options nosniff to stop MIME sniffing. X-Frame-Options DENY or CSP frame-ancestors to prevent clickjacking. Referrer-Policy strict-origin-when-cross-origin to avoid leaking URLs. Permissions-Policy to disable browser features you don't use. The cross-origin isolation headers (COOP/CORP) for Spectre hardening. And on the cookie side, HttpOnly, Secure, and SameSite. Plus removing information-disclosure headers like Server and X-Powered-By. The framing is that these are cheap defense-in-depth layers that are table stakes.

401 Unauthorized actually means unauthenticated — the server doesn't know who you are, so authenticate and try again. 403 Forbidden means you're authenticated fine but you're not permitted to access this resource, so retrying with the same identity won't help. The naming is historically confusing, so I remember it as 401 = "who are you?" and 403 = "no." A security nuance is that some apps return 404 instead of 403 for sensitive resources so attackers can't even confirm a resource or admin path exists, reducing enumeration.

Because query strings end up in far more places than the request itself. They're written to server access logs and proxy/load-balancer logs, they're stored in browser history, they're sent in the Referer header to third-party sites the page links to or loads resources from, and they can be cached. So a session token, password, or PII in a URL leaks into logs and analytics across multiple systems where it's hard to scrub and easy to expose. Sensitive data belongs in the request body of a POST, or in a header, not in the URL.

CSP is a response header telling the browser which sources of scripts, styles, and other content are allowed to load and execute, acting as a second line of defense if an XSS payload gets injected. A strong policy forbids inline scripts and only allows scripts from trusted origins or those carrying a per-request nonce, so an injected script tag simply won't run — it isn't from an allowed source and lacks the nonce. It doesn't replace output encoding; it's defense-in-depth, and the mistake that guts it is allowing unsafe-inline. I'd deploy it report-only first to find legitimate breakage, then enforce, ideally nonce-based with strict-dynamic.

no-store tells browsers and any intermediary caches never to store the response at all — not on disk, not in memory. It matters for any response containing sensitive data: authenticated pages, anything with PII, session tokens, or financial data. Without it, a response can be cached on the device or, worse, on a shared proxy or CDN, where it might be served to another user or recovered later from a shared machine. It's distinct from no-cache, which permits storing but requires revalidation before reuse. For sensitive pages you want no-store, often alongside private and a Vary on Cookie so user-specific content is never served to the wrong person.