Security and Pitfalls

JSON cannot run code: it has no functions, no references and no includes. That makes it much safer than many formats, and it also makes people careless. Almost every JSON security problem is really about what the program does with the data: it trusts a number it cannot represent, lets two components read the same text differently, merges an attacker's keys into an object, builds JSON out of strings, or accepts a document of any size and depth. This chapter shows each problem happening, then the fix, using the tools from the earlier chapters. All demonstrations are harmless (they print a message or set a variable) and run only against my own scratch files and a server on 127.0.0.1.

1. Numbers Beyond 2⁵³: Use Strings for IDs

The JSON grammar has no limit on a number's size; the program that reads it does. I fed the same text, {"id":9007199254740993,"price":0.1}, to three tools:

Two different records can have ids that differ only in the last digit; after Node reads them they are the same record. For the security angle: an access check on "id 9007199254740993" in one component and a lookup on "id 9007199254740992" in another is a bug an attacker can aim at. Send identifiers (and money, and anything with more than 15 significant digits) as strings (Chapters 1 and 2 explain the precision limit and the rawJSON alternative).

2. Duplicate Keys: Two Readers, Two Answers

The standard says object names "SHOULD be unique" and does not say what happens otherwise. All three tools I ran (Node, Python, jq) take the last value: for {"role":"user","role":"admin","n":1,"n":2} every one of them gave role "admin" and n 2. I did not find a first-wins parser among the tools I ran, but other parsers exist that behave differently (I did not test any), and the attack needs only one pair of components that disagree: a gateway that checks the first role and a backend that obeys the last. To show the shape of the problem I wrote a small first-wins reader myself (labelled as a simulation in the output):

The strict hook caught a duplicate nested inside an array (tags[0].a) as well. Note that the hook runs from the inside out, so it reported the inner duplicate 'a' before it reached the outer role. Parsing and then re-serialising (json.dumps(json.loads(doc))) produces a document with one role, which removes the ambiguity for whatever reads it next, but only if the security check happens after that step. Node's JSON.parse has no option to reject duplicates: in section 9 I use a small scanner for it.

3. Prototype Pollution in JavaScript

Every JavaScript object inherits from Object.prototype. If an attacker can set a property on that shared prototype, every object in the program gains it. The route is a key named __proto__ (or constructor.prototype) in JSON that a program merges into an object. I tested the pieces separately with the payload {"name":"x","__proto__":{"isAdmin":true}}:

The lesson is that the parser was not the problem; the merge was. The same is true of "clone", "set by path" and "extend" helpers, and published packages have had exactly this bug. (I wrote my own functions and did not test any library.) Use a Map or a null-prototype object for data keyed by user-supplied names, reject or remove the three names at the boundary, and keep untrusted data out of generic merge helpers.

4. Never eval JSON, and the Other Formats That Run Code

Before JSON.parse existed, people turned JSON into data with eval. I fed both approaches a document with a call hidden in a value:

Honest JSON works with eval too, which is why the habit lasted. A real attacker's value would not print a message. The same class of bug lives in other formats' loaders, and I ran two harmless demonstrations (each makes the loader call print):

• pickle.loads called the function named inside the data (__reduce__ returned print and an argument): "code ran during pickle.loads". Never unpickle data you did not make.
• PyYAML: yaml.load(..., Loader=yaml.UnsafeLoader) on the text !!python/object/apply:builtins.print ["..."] called print. yaml.safe_load refused the same text with a ConstructorError. The same text inside a JSON string is only data.

So the safe habit is: JSON goes through JSON.parse or json.loads, YAML through safe_load, and nothing that can instantiate arbitrary types through untrusted input. JSON's lack of features is the protection; keep it that way.

5. Depth and Size: Denial of Service

A parser needs memory for what it reads, and some code recurses once per nesting level. Chapter 9 measured the memory side; here is the depth side. I generated nested arrays ([[[[...]]]]) and tried each operation:

The "about" figures came from a single binary search each and move with the stack size and the program's state, so treat them as orders of magnitude. The point is that different layers fail at different depths, and the failures are exceptions, not security holes, but an uncaught one in a request handler is an easy way to knock a service over. Cap the body size before reading it all, cap the depth (64 is generous for almost any API), and catch the errors.

jq has had its own memory-safety fixes. As summarised from jq's NEWS: 1.8.0 fixed CVE-2024-23337, a signed integer overflow in array and object internals, by limiting them to 2²⁹ elements; 1.8.2 fixed a number of issues including CVE-2026-40164 (crafted keys that collide in the hash table, causing high CPU use from about 100 KB of JSON; it now randomises the hash seed) and capped recursion depth in several functions. On 1.8.2 I tried jq -n '[] | .[999999999999] = 1' and got "Array index too large" instead of an allocation. If you process untrusted JSON with jq, run a current version (jq --version).

6. Injection: Never Build JSON with String Concatenation

The name contained a quote, a comma and a new key, and with string concatenation it became JSON structure. Two things I observed that are easy to miss. First, the attack only worked when the injected key came after the real one: in the template that put the name first ({"user":"NAME","role":"user"}) the later real role overwrote the injected one, because parsers take the last duplicate (section 2). So the order of fields decided whether the attack worked, which is no defence. Second, the same concatenation breaks on innocent input: a name with a plain double quote made the parser fail ("Expecting ',' delimiter"), and a name containing a backslash followed by t (C:\temp) was silently turned into a tab. JSON.stringify and json.dumps escape correctly; use them for every value.

JSON inside HTML

A common pattern puts JSON in a <script> block. JSON.stringify does not escape <, so a value containing </script> ends the script block early and the rest is read as HTML:

The escaped form contains no raw <, so the browser cannot find a closing tag in it. (I checked the strings and the round trip, not the browser rendering of this particular page. The next section does run a browser.) Since ES2019 a raw U+2028 inside a JSON string is also legal JavaScript, so it no longer needs special handling in a script block; I tested that in Node only.

Content-Type: a Browser Does What the Header Says

I wrote a tiny server with two routes that echo a query parameter inside a JSON object, {"q":"..."}. One labels the response text/html, the other application/json; charset=utf-8 with X-Content-Type-Options: nosniff. I opened both in headless Chrome 154 with q=<script>document.title='RAN'</script> and dumped the page:

So: always send JSON as application/json, and add X-Content-Type-Options: nosniff. (I did not test what Chrome does with application/json without nosniff, or any other browser.) The old "JSON hijacking" attack is a related historical case: a site returned a top-level array of private data, and a hostile page loaded it with a <script src> tag and overrode the browser's array constructor to read it. That relied on old browser behaviour; I did not reproduce it. Modern guidance is the same as above (correct content type, authentication that does not rely on cookies alone, and an object at the top level rather than a bare array), but check current OWASP guidance for your situation.

7. Sensitive Data in Logs

JSON is easy to log whole, and that puts passwords and tokens in log files. Redaction by key name is simple (a replacer function in JavaScript, walk in jq) and I ran both. It also has limits, which the test exposed:

• It removed password, profile.ssn, items[0].token and the Authorization header at any depth.
• It missed a free-text field ("note": "my password is hunter2") and a key I had not listed ("pw"): both still contained the secret. A list of names protects only the names on the list; an allow-list (log only the fields you choose) is safer.
• Error messages can leak too: Node's parser error for the text password=hunter2 was Unexpected token 'p', "password=hunter2" is not valid JSON, which quotes the input. Do not log a parse error together with the body that caused it.

8. A Front Gate for Untrusted JSON

Putting the limits together, here is a small gate I wrote for Node: check the content type, the byte size, then scan the text once for depth and duplicate keys, then call JSON.parse. The scanner ignores braces inside strings, handles escaped quotes, and decodes keys before comparing them (so "a" and "\u0061" count as the same key).

Behind a small HTTP server the same gate returned 200 for good JSON, 400 for a duplicate key, for depth 100 and for malformed JSON, 415 for text/plain, and 413 for a 2 MB body (the status codes are my choices). The gate is deliberately small: it does not validate the shape (use JSON Schema, Chapters 6 and 7, after the gate), it does not stop a flood of requests, and it is a scanner I wrote, not a hardened library: I tested the cases in the table and no others. In production, also put a size limit in the web server so an oversized body never reaches your code.

Checklist

Exercises