flawopen.com/Insecure Deserialization/JSON.parse() vs eval()

Is JSON.parse() safe, or can it be exploited like eval()?

Reference page — draft, pending review
Short answer

JSON.parse() is safe from the code-execution risk that older code using eval() to parse JSON carried. It parses data only — it never executes any code found in the string, unlike eval(), which treats its argument as executable JavaScript.

DANGEROUS — legacy pattern
// old code sometimes did this
const data = eval("(" + untrustedJson + ")");
// untrustedJson could contain any JS,
// not just valid JSON
SAFE
const data = JSON.parse(untrustedJson);
// parses data only, never executes code

Why this question comes up

Before JSON.parse() was widely available, some older JavaScript code used eval() to parse JSON strings, since valid JSON is also mostly valid JavaScript object-literal syntax. This was a real, exploitable code-execution vector — an attacker-controlled "JSON" string could contain arbitrary JavaScript instead of just data, and eval() would run it. JSON.parse() was specifically designed to close this gap: its parser only recognizes JSON's data grammar and has no code-execution path at all.

What JSON.parse() still doesn't protect against

Safety from code execution doesn't mean the resulting data is automatically safe to use everywhere — a string value inside parsed JSON can still carry an XSS payload if later rendered into HTML unescaped, or SQL-injection-shaped content if later concatenated into a query. JSON.parse() solves the deserialization-to-code-execution problem specifically; it doesn't make the parsed values trusted for every downstream use.

FAQ

Is there any remaining reason to use eval() for parsing?

No — JSON.parse() is faster, safer, and universally available in any environment that would run this code. There's no remaining justification for the eval() pattern.

References