An HTTP/1.1 transfer method that sends a request or response body in segments when the final size is not known in advance. Each chunk includes a length field, and the receiver uses that value to decide how much data to read next. Weak validation here can create parsing and safety problems.
How Chunked Transfer Encoding Works
Chunked transfer encoding is an HTTP/1.1 body framing method used when the sender does not know the final payload length in advance. Instead of waiting to compute a Content-Length value, the sender streams the body as a sequence of chunks, each preceded by its size in hexadecimal.
The receiver reads one chunk length, consumes exactly that many bytes, then repeats until it encounters the terminating zero-length chunk. This makes the transfer efficient for generated content, streaming responses, and proxy chains where data may be produced incrementally.
Why It Exists in HTTP/1.1
The main value of chunked transfer encoding is that it separates message delivery from prior knowledge of message size. That helps applications start sending data immediately, avoids buffering large bodies just to calculate a length, and supports dynamic responses that are assembled on the fly.
It is a transport framing feature rather than a content-format feature, so the application payload can still be JSON, HTML, binary data, or any other media type. In practice, chunked encoding is often handled transparently by web servers, reverse proxies, application servers, and client libraries.
Parsing Rules and Intermediary Behavior
Correct parsing depends on strict interpretation of the chunk size, the chunk terminator, and the final zero-length chunk that marks the end of the message body. Intermediaries must preserve that framing exactly, because any disagreement about where the body ends can create ambiguity between components.
This matters especially in layered HTTP deployments where one component decodes the chunks and another reuses the connection. If a proxy, gateway, or origin server interprets the message differently, the same byte stream can be understood in more than one way, which undermines trust in the request boundary.
Security Implications of Chunked Encoding
Chunked transfer encoding is not inherently insecure, but it becomes risky when parsers disagree, when validation is weak, or when chunk syntax is handled inconsistently across intermediaries. Those conditions can create request smuggling and request desynchronization conditions, especially in front of shared proxies and application gateways. OWASP API Security Top 10 is also relevant where body framing mistakes expose API gateways to broken parsing assumptions.
Because the framing controls how much data each component believes belongs to the message, even small parsing differences can have security impact. Defensive parsing must be deterministic, and implementations should reject malformed chunk sizes, invalid delimiters, and ambiguous transfer-coding combinations rather than trying to recover.
Risk and Threat Considerations
Weak chunk parsing can let an attacker hide or split bytes in ways that upstream and downstream components interpret differently. That creates a practical path to desynchronization, request smuggling, cache poisoning, and other boundary-confusion attacks in HTTP stacks that reuse connections or sit behind multiple parsers.
Failure mechanism: The sender, proxy, and origin do not agree on where one HTTP message ends and the next begins, so attacker-controlled bytes are treated as part of a different request or response than the defender expects.
Impact: This can enable unauthorized request injection, bypass of security controls at the edge, poisoning of shared intermediaries, and unpredictable application behavior that is hard to detect and reproduce.
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 and risk surface, while NIST SP 800-53 Rev 5, NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP API Security Top 10 | API8 — Security Misconfiguration | Chunked framing failures often stem from parser and gateway misconfiguration. |
| Recommendation — Harden API and gateway parsing to reject ambiguous chunked bodies and preserve a single canonical message boundary. | ||
| NIST SP 800-53 Rev 5 | SI-10 — Information Input Validation | Chunk sizes and delimiters must be validated before body data is processed. |
| SC-8 — Transmission Confidentiality and Integrity | HTTP body framing errors can undermine trust in data carried across network boundaries. | |
| Recommendation — Validate transfer-coding syntax strictly and reject malformed chunked input before downstream processing. Protect HTTP transport paths so message framing and body contents cannot be altered in transit. | ||
| NIST CSF 2.0 | PR.DS-01 — Data-at-rest is protected | Strict message handling supports integrity of data being received and stored by services. |
| Recommendation — Preserve integrity of inbound message data by enforcing unambiguous parsing at trust boundaries. | ||
| CIS Controls v8 | CIS-16 — Application Software Security | Web application parsing behavior is part of secure software handling of external inputs. |
| Recommendation — Test application and proxy handling of chunked requests to catch parser-differential weaknesses. | ||
