HTTP is the standard web protocol that lets clients and servers request and deliver pages, APIs, and other resources. It defines methods, headers, and status codes for stateless application communication over TCP or QUIC, forming the transport layer used by browsers, services, and many identity, cloud, and security controls.
How HTTP Works
HTTP is the request-response protocol that makes the web and many API calls possible. Clients send methods such as GET or POST, servers return responses with headers and status codes, and the protocol stays stateless so each request can be handled independently.
That stateless design is a strength because it keeps application traffic simple and scalable, but it also means security state usually lives elsewhere, in sessions, tokens, cookies, gateways, or application logic. HTTP itself does not decide whether a caller should be trusted; it only carries the exchange that higher layers interpret.
Where HTTP Sits in the Stack
HTTP runs above TCP or QUIC and below the application that actually delivers content or business logic. In practice, it is the common transport for browsers, microservices, reverse proxies, identity flows, and many control planes, which is why it appears everywhere in modern infrastructure.
Because HTTP is so widely reused, it becomes a shared dependency across web applications, APIs, observability tools, and security products. A weakness in how an organisation terminates, forwards, or inspects HTTP traffic can therefore affect multiple services at once, even when the business logic behind those services is unrelated.
HTTP Methods, Headers, and Status Codes
The main building blocks of HTTP are methods, headers, and status codes. Methods express intent, headers carry metadata such as content type, cache directives, authentication material, and routing hints, and status codes tell the client whether a request succeeded, failed, or needs further action.
These fields are operationally important because they shape how intermediaries and applications behave. Misused headers can leak information or weaken trust boundaries, while ambiguous status handling can make authentication, authorization, caching, or error handling behave in ways the developer did not intend. For that reason, HTTP security is often really about the correctness of the application and the proxies that interpret it.
Why HTTP Still Matters for Security
HTTP is foundational to web security because so many controls, from login flows to API gateways and browser protections, depend on its semantics. The protocol is not inherently unsafe, but plain HTTP, weak header handling, and poor separation between trusted and untrusted traffic can expose credentials, sessions, data, or request metadata to interception or abuse.
Modern deployments typically rely on HTTPS, which layers HTTP over TLS, to protect confidentiality and integrity in transit. Even then, security teams still need to understand HTTP behavior because proxy chains, load balancers, caching layers, and application frameworks may alter requests and responses in ways that affect exposure, logging, or access decisions.
Risk and Threat Considerations
HTTP is a high-value attack surface because it carries authentication, session data, API calls, and user-controlled input across trust boundaries. Weakly protected HTTP traffic can be intercepted, replayed, smuggled, cached incorrectly, or used to manipulate downstream services.
Failure mechanism: Attackers exploit the gap between what the client sends and what intermediaries or applications believe they received, especially when parsing rules, header handling, or transport security are inconsistent.
Impact: The result can be credential theft, session hijacking, request forgery, access-control bypass, data exposure, or corruption of upstream and downstream application state.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 addresses the attack surface, NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP API Security Top 10 | API8 — Security Misconfiguration | HTTP gateways and API behavior depend on correct security configuration. |
| Recommendation — Harden HTTP-facing APIs so headers, methods, and trust boundaries are configured consistently. | ||
| NIST SP 800-53 Rev 5 | SC-8 — Transmission Confidentiality and Integrity | HTTP traffic often needs protection in transit to preserve confidentiality and integrity. |
| IA-5 — Authenticator Management | HTTP commonly carries sessions and credentials that need lifecycle protection. | |
| Recommendation — Use protected transports for HTTP exchanges that carry sensitive data or credentials. Protect HTTP-borne credentials and tokens with strong issuance, rotation, and revocation controls. | ||
| CIS Controls v8 | CIS-13 — Network Monitoring and Defense | HTTP traffic is a primary source of observable web and API security activity. |
| Recommendation — Inspect HTTP flows for anomalies, abuse patterns, and unexpected request paths. | ||
| ISO/IEC 27001:2022 | A.8.20 — Network security | HTTP sits on network paths that require secure control and protection. |
| Recommendation — Apply network security rules that protect HTTP services and their trust boundaries. | ||
Practitioner Guidance
Why practitioners should care: HTTP is not just a delivery format, it is the control plane for how most web and API security decisions are expressed in motion. Treat method handling, header trust, and proxy behavior as part of the security design, not just as implementation detail.
What to watch for: Pay close attention to inconsistent behavior between clients, proxies, gateways, and origin servers, because that is where real-world HTTP abuse often appears. A request that looks harmless at the edge can become dangerous once parsed differently deeper in the stack.