How do you defend json.loads against a deeply nested untrusted document?

## Why nesting is a cost at all `json.loads` is a recursive-descent parser: to read an array it reads values, and a value may itself be an array, so the parser calls itself. Depth of nesting in the document becomes depth of recursion in the parser, and depth of recursion becomes stack. The attacker's leverage is that nesting is *cheap to write and expensive to read* — one byte per level. A 200 KB body consisting of nothing but `[` buys 200,000 levels. ```python import json, sys print(sys.getrecursionlimit()) # 1000 json.loads("[" * 100_000 + "]" * 100_000) # RecursionError: Stack overflow (used 3906 kB) while decoding a JSON # array from a unicode string ``` Two things in that transcript matter. It raises rather than crashing — CPython now checks how much C stack remains and turns exhaustion into an exception on supported platforms, which is a hardening improvement over older releases where deep C recursion could take the process down. And the number it reports is *kilobytes of stack*, not a count of Python frames, which is the clue that `sys.getrecursionlimit()` is not the bound in play. ## Why raising the recursion limit is not the fix `sys.setrecursionlimit()` sets the limit on **Python** frames. Since 3.12 CPython maintains a separate guard for **C-level** recursion, and that function does not raise it. The C accelerated scanner in `json` is bounded by the C guard, so pushing the Python limit up changes nothing: ```python sys.setrecursionlimit(200_000) json.loads("[" * 100_000 + "]" * 100_000) # still RecursionError ``` That separation is deliberate and is a good thing. Before it existed, raising the limit far enough genuinely could let a C-level parser run off the end of the real thread stack and segfault — trading a catchable exception for a process death, and on a worker that handles other requests, that is strictly worse. Treat any `sys.setrecursionlimit(100000)` in a service as a defect: it is either useless or dangerous, and never a bound on attacker-controlled input. Threads make it sharper still. A thread gets whatever stack `threading.stack_size()` was set to before it started, typically smaller than the main thread's, so a document that parses on the main thread can fail on a worker thread. Depth limits you rely on must be *your* limits, checked in your code, not whatever the platform's stack happens to allow. ## The swallowed-exception trap `RecursionError` is a subclass of `RuntimeError`, and therefore of `Exception`. Picture a CSV import for a payroll system where each row carries a JSON blob of allowance details, and the row loop is written defensively: ```python for row in reader: try: record = json.loads(row["details"]) except Exception: continue # "one bad row shouldn't kill the import" apply(record) ``` A crafted or merely corrupt cell now vanishes silently. Nothing is logged, the import reports success, and the effect surfaces a fortnight later as a missing allowance on somebody's payslip. The bug is not the parser — the parser did exactly the right thing and raised — it is that a bare `except Exception` cannot tell a malformed record from an attack from a bug in your own code. Catch precisely and record what you dropped: ```python except (json.JSONDecodeError, RecursionError) as exc: log.warning("rejected row %s: %s", row["id"], exc) rejected += 1 ``` and fail the import if `rejected` crosses a threshold. A silent skip is a decision to lose data; make it a visible one. ## The defences that actually bound the attack **Cap the bytes first.** A hard limit on request-body size, enforced before you have the string in memory, is the cheapest control and the one that bounds every other parser cost too. Note it does not bound depth on its own: a 1 MB cap still permits a million levels, which is far past anything legitimate. **Cap the depth explicitly.** Decide what your contract allows — most real schemas are under ten levels deep — and enforce it. Either pre-scan the bytes counting brackets that lie outside string literals, or use a streaming/iterative parser that reports depth as it goes and lets you abort early. Enforcing your own small number is what makes the behaviour identical on every platform, thread and interpreter build. **Isolate what you cannot bound.** If a feature must accept arbitrary documents, parse them in a child process with a wall-clock and memory bound, so the worst case is a killed child and a rejected request rather than a stalled worker. **Remember the output side.** `json.dumps` recurses too. Serializing a deeply nested structure you built from untrusted input hits the same wall, and a structure containing a reference back to itself raises `ValueError` for a circular reference rather than looping forever. The general lesson generalizes past JSON: any recursive-descent parser turns one byte of input into one frame of stack, so untrusted input into such a parser always needs an explicit, self-imposed depth bound.