A proxy compares a numeric field against a limit and forwards the body: how can the backend see a different number?

## Text on the wire, a type in memory A self-describing text encoding writes numbers as decimal text and says almost nothing about range or precision: JSON's grammar permits an optional sign, digits, an optional fraction and an optional exponent, with no limit on how many digits appear. The data model does not name a machine type. Every decoder therefore chooses one, and that choice is where two components stop agreeing. The three common targets behave differently on the same input: | Target type | Exact for | Behaviour on excess | |---|---|---| | IEEE 754 binary64 | integers up to 2^53; values on the binary grid | rounds to the nearest representable value; becomes an infinity past the range | | 64-bit two's-complement integer | integers in the signed 64-bit range | rejects, truncates a fraction, or wraps, depending on the decoder | | Arbitrary-precision decimal | every digit written | no loss; cost is memory and slower arithmetic | ## The arithmetic that makes the bypass concrete Binary64 carries a 53-bit significand. Every integer up to **2^53 = 9007199254740992** is representable exactly; above that, only every second integer is, so `9007199254740993` decodes to `9007199254740992` — the nearest representable neighbour. An identifier compared for equality after that conversion matches a value the client never sent. The same gap appears with fractions, and it is the cleaner attack. Near `10000` the exponent is fixed and adjacent binary64 values are 2^-39 apart, roughly 1.8 x 10^-12. The text `10000.000000000000001` differs from `10000` by 10^-15, far below that spacing, so it decodes to **exactly 10000**. A proxy evaluating `amount <= 10000` over a binary64 value approves it. A consumer that decoded the same text into an arbitrary-precision decimal reads a value strictly greater than `10000` and, if it enforces the same rule, would have refused it — but it is not the component enforcing the rule. Reverse the roles and the divergence still pays: a precise checker and a rounding consumer let a value that failed the check be applied at a rounded-down amount, which is the shape behind quantity and price mismatches. ## Coercion, the second axis Beyond precision, decoders disagree about what counts as a number at all: - **Quoted numerics.** A lenient binder accepts `"10000"` for a numeric field and coerces it; a strict one rejects the document. A checker that skips non-numeric values entirely then never evaluates the rule at all — the field is present, unchecked, and used downstream. - **Spelling.** A leading `+`, a leading zero, an exponent form such as `1e4`, or surrounding whitespace are accepted by some decoders as extensions and refused by others, so the two sides may not even agree that a value exists. - **Special values.** Text such as an infinity or a not-a-number token is outside the JSON grammar but accepted by lenient decoders. A comparison against a limit is **false** for a not-a-number value, so a rule written as "reject when above the limit" silently passes it while "accept only when at or below the limit" refuses it. The polarity of the comparison decides the outcome. - **Out-of-range.** One decoder raises an error, another saturates to the type's maximum, a third yields an infinity. Each is a different number for the check to compare. ## Defences, in the order to propose them 1. **Compare on the consumer's representation.** If the consumer uses an arbitrary-precision decimal, the checker must too. Sharing a representation is more reliable than sharing an implementation. 2. **Constrain numbers at the boundary.** Reject fractional digits beyond the scale the domain actually uses, reject magnitudes outside the consumer's exact range, reject exponent and quoted forms. This shrinks the set of documents any two decoders can read differently. 3. **Carry money and identifiers as strings with an explicit scale**, decoded deliberately rather than by the generic number path. This removes the decoder's type choice from the security argument entirely. 4. **Test differentially.** Feed both decoders values at the boundaries — 2^53 and just above, the limit plus a digit beyond binary64 spacing, the signed 64-bit extremes — and compare what each produces. ## What interviewers are listening for The weak answer is "floating point is imprecise". The strong answer names *where* the imprecision falls relative to a specific limit, states that the disagreement is between two target types rather than a bug in either, and then observes that the check and the use are running on different representations — which is the same invariant that governs every parser differential.