What HTTP represents
An HTTP request has a method, target, protocol context, field section, and optional content. A response has a status code, fields, and optional content. The authority identifies the target origin. Intermediaries can route, transform, cache, retry, authenticate, and enforce policy within protocol rules.
Security-relevant semantics
Methods express requested semantics but do not guarantee application behavior. Safe and idempotent properties affect retries and caching. Status codes describe the server response, not business completion. Fields have defined combination and forwarding rules. Message framing must be unambiguous across intermediaries.
Access decisions
Bind policy to trusted route selection, normalized method, authority, path, and required fields. Do not trust a client-supplied identity field. Remove hop-by-hop state correctly. Protect credentials and sensitive content from logs, redirects, caches, and URLs.
Failure and residual risk
Parser disagreement can cause request smuggling. Automatic redirects or retries can change credential exposure or duplicate actions. Caches can serve data across identities. A successful status can still represent an unauthorized application action.
Pomerium boundary
Pomerium routes and authorizes supported HTTP requests and proxies them to configured upstreams. Applications own method and object semantics, cache controls, final action authorization, and safe idempotency. Operators own intermediary compatibility and direct-path isolation.
Evaluation checklist
- What method, authority, target, fields, content, and protocol version does the request use?
- Which values are normalized before routing and policy?
- Can redirects, retries, caches, or parser differences change the security result?
- Which identity fields are created only by a trusted intermediary?
- Does application evidence confirm the final object action?
