HTTP and proxies

A web page may create many HTTP exchanges: loading a picture, checking a basket, or saving an address. Reading one request and its response helps you explain what happened. It does not, by itself, prove that the application made the right security decision.

GET /catalog HTTP/1.11
Host: books.example2

HTTP/1.1 200 OK3
Content-Type: application/json4
{"items":3}5

A request describes an operation

The method states the intended operation. The target names the resource; headers carry metadata; some requests include a body. HTTP versions encode these details differently while retaining shared semantics.

GET is defined as safe: the client is requesting retrieval rather than a state change. Incidental logging is compatible with that definition. A GET that deletes an account violates the intended semantics and creates risks from automatic retrieval. Idempotence means repeating an operation has the same intended effect as doing it once; the responses and logs need not be identical. These distinctions come from HTTP semantics.

Status is a clue, not the whole answer

A 2xx response reports successful handling under the status’s meaning, not correct authorization. A successful HEAD response has no content body. A 3xx response is not always a redirect to a different location: 304 relates to cache validation.

401 concerns missing or invalid authentication credentials; 403 means the server refuses the request. Applications may deliberately use 404 to conceal a resource. Read the documented behavior, response body, and relevant server evidence together.

Cookies carry values

A cookie may hold a preference, a session identifier, or other state. Secure restricts transmission to secure channels; HttpOnly prevents script access through cookie APIs; SameSite affects attachment to cross-site requests. Domain and Path control delivery, but Path is not a reliable isolation boundary between applications.

These attributes complement session expiration and authorization. They do not establish that the current user may read a particular receipt.

TLS and proxies have different jobs

TLS protects a connection against network observation and modification when peers and trust are validated correctly. It cannot decide whether a refund is legitimate. A forward proxy serves clients; a reverse proxy sits in front of services. A debugging proxy can inspect HTTPS only when the client and traffic are configured to trust and use it. Some traffic is merely tunneled.

Only designated trusted proxies should supply identity-related forwarding information, with the application handling untrusted incoming values consistently.

Scenario: the receipt that stayed in cache

Mina signs out of a shared tablet. The next shopper sees Mina’s receipt. Several explanations remain possible: application state, browser history, local caching, or a shared cache. The team identifies the actual storage layer before choosing controls.

Authenticated responses are not automatically unsafe to cache. They need policies suited to their sensitivity and sharing rules. CORS is another separate boundary: it governs browser access to cross-origin responses. A wildcard allowed origin does not permit credentialed sharing under Fetch; browsers reject that combination. Server authorization remains necessary.

A useful note records the operation, the expected permission, the observed result, and which component supplied the evidence.

Choose a policy from an actual requirement

The fictional shop has two requirements. Public catalog responses may be reused for sixty seconds. Receipts must not be stored by HTTP caches. Compare these proposed receipt policies:

For the non-personalized public catalog, public, max-age=60 permits shared storage and a sixty-second freshness lifetime, subject to HTTP cache rules. This is the shop’s stated policy, not a recommendation for every catalog. Only the third receipt proposal matches its no-storage requirement. These are response directives without field-name arguments. They govern compliant HTTP caches; they are not deletion commands for screenshots, exported files, or all application-managed storage.

Trace the connections too. Suppose TLS ends at the shop’s reverse proxy, which starts a separate connection to the application. Browser certificate validation covers the browser-to-proxy connection. The proxy-to-application path needs its own documented protection and peer validation. A lock icon cannot establish that second configuration.

The review note should therefore separate three claims: the selected cache directive meets a stated requirement, the observed copy came from a particular storage layer, and each network connection has the intended protection. Evidence for one does not establish the others.