Why can bytes placed after a complete JSON document change what a second decoder in the chain sees?

## The question every decoder has to answer After a decoder reads one complete value from a buffer, something must happen with whatever bytes remain. There is no single right answer, because decoders serve different callers: - A decoder built for **a single document per payload** naturally requires end-of-input and reports an error when bytes follow the closing brace. - A decoder built as **a streaming reader over a long buffer** naturally stops at the end of the value and hands back a cursor, leaving the caller to decide whether to read again. If the caller does not look, the remainder is silently discarded. - A decoder built for **a sequence of documents** — the line-delimited style used for logs and bulk records — reads value after value and returns them all, or, through a convenience entry point, the last one. Each of these is correct for its purpose, and any two of them in one request path disagree about the same bytes. ## The shape of the divergence Consider a body carrying two complete objects back to back: `{"role":"user"}{"role":"admin"}` | Decoder behaviour | Result | |---|---| | Stop after the first value | one object, `role` is `user`, remainder ignored | | Require end-of-input | a decode error, the document is refused | | Read a sequence, keep the last | one object, `role` is `admin` | An inspecting proxy of the first kind approves the request. A consumer of the third kind applies the second object. Nothing logged an anomaly anywhere, because from each component's own point of view the payload parsed cleanly. ## Related leniency that lives in the same seam The trailing-bytes question is one instance of a larger disagreement about what is tolerated around and inside a document: - **A byte-order mark or stray whitespace before the opening brace**, skipped by one decoder and treated as a syntax error by another. - **Comments and trailing commas**, accepted by decoders that implement a common superset of the format and rejected by strict ones. - **Control characters inside strings** that the grammar requires to be escaped, silently accepted by some decoders. - **Truncated input**: a decoder that returns whatever it has assembled so far, against one that demands a complete value. Every item on that list is a way for one payload to mean two things, which is the only ingredient a parser differential needs. ## Why this one is under-tested Functional tests never produce these inputs. Client libraries emit a single well-formed document and stop, so the trailing region is empty in every legitimate request, and the divergence is invisible until someone constructs the input deliberately. Fuzzing that only mutates *inside* the document misses it too — the mutation has to append a second complete value, which a structure-aware generator will not do unless it is told to. The cheap test is direct: take a valid body, append a second complete document that differs in one security-relevant member, send it, and observe which value the system acted on. If the two differ from what the inspecting component logged, the chain has the defect. ## Closing it - **Demand end-of-input at the boundary.** The component that inspects the payload should use a decoder mode that refuses anything after the first complete value, so ambiguous bodies are rejected rather than resolved. - **Turn lenient extensions off on the inspecting side**, and prefer them off everywhere: comments and trailing commas buy nothing on a machine-to-machine path and cost a divergence class. - **Forward the decoded document, not the received buffer**, which removes the trailing region from the consumer's view entirely. - **Do not rely on matching the two decoders' settings by policy.** Settings drift with upgrades and with whoever writes the next service; a boundary that rejects the ambiguous document does not depend on the other side's configuration at all. The framing to keep: the security-relevant property is not "is this document well formed" but "do both decoders agree on where it ends and what it contains". The second is the stronger question, and only the boundary can answer it for the whole chain.