JSON interoperability becomes a security problem when two components read the same bytes differently. A gateway may validate one value while an application keeps another duplicate key; a signature layer may preserve a large integer while a binary64 consumer rounds it; one service may reject comments or trailing bytes while another quietly accepts them. The document alone is not an exploit, but disagreement across an authorization or trust boundary creates the condition an attacker can target.
This lab tokenizes the input once and compares explicit semantic profiles: strict RFC 8259, first-key-wins, last-key-wins, permissive JSON-like syntax, and binary64 number handling. These are transparent models, not claims that Go, Python, Java, Node.js, or any named library was executed in your browser. Real parser behavior depends on the exact implementation, version, options, and surrounding code.
The analysis covers the issue families that produce meaningful interoperability differences: duplicate and decoded-equivalent keys, comments, trailing data, invalid or non-finite numbers, unsafe integers, malformed escapes, unpaired surrogates, literal control characters, byte-order marks, and excessive nesting. Every result includes the source offset and nearby evidence so the finding can be reproduced rather than trusted as a black-box verdict.
Use the grid to decide what to test at the real system boundary. The durable fix is not choosing the profile you prefer—it is making every component enforce one documented grammar, duplicate-key policy, numeric representation, Unicode policy, and resource limit before security decisions are made.
Edge cases worth knowing
- Duplicate authorization keys
- {"role":"user","role":"admin"} is valid under the JSON grammar, but RFC 8259 calls object names unpredictable when they are not unique. First-key and last-key consumers can authorize different identities from identical bytes.
- An integer beyond the safe binary64 range
- 9007199254740993 is valid JSON, yet an IEEE-754 binary64 consumer cannot represent it exactly. That matters when IDs, quotas, signatures, or money cross from exact-decimal parsing into JavaScript-style numeric handling.
- Unicode-equivalent key spellings
- A key written with a composed character and one written with combining code points can normalize to the same visible identifier. The lab reports the collision but does not assume every downstream system normalizes keys.
Common mistakes
- Calling a semantic profile a specific language or library parser without executing and pinning that exact implementation and version.
- Treating duplicate keys as harmless because one local JSON parser consistently keeps the last value.
- Assuming syntactically valid JSON guarantees exact numeric or Unicode round trips across services.
- Calling parser disagreement an exploit without establishing that the disagreeing consumers sit across a security boundary.