Security Auditing of JSON Formatter Implementations

JSON formatters are widely used tools or libraries that take raw JSON text and render it in a human-readable, syntax-highlighted, and often interactive way. While they seem like simple utilities, their implementation can introduce security vulnerabilities if not handled carefully. This guide covers common risks and how to audit and mitigate them.

Why Audit a JSON Formatter?

A JSON formatter's primary job is to display potentially untrusted user-provided data (the JSON string). If this data contains malicious content and the formatter's rendering logic doesn't handle it properly, it can lead to security issues in the application hosting the formatter. This is especially critical in web applications where the formatter runs in the user's browser.

Common Vulnerabilities

1. Cross-Site Scripting (XSS)

This is arguably the most common and significant risk. JSON values, especially strings, can contain malicious HTML or JavaScript. If the formatter directly renders these values into the DOM without proper escaping, the attacker's code can be executed in the user's browser.

{
  "name": "<script>alert('XSS')<\/script>",
  "description": "<img src='x' onerror='alert(\'XSS 2\')'>"
}

<div>
  <span class="key">"name":</span>
  <span class="string"><script>alert('XSS')<\/script></span> <!-- Script executes! -->
</div>
<div>
  <span class="key">"description":</span>
  <span class="string"><img src='x' onerror='alert(\'XSS 2\')'></span> <!-- Image tag executes JS! -->
</div>

Auditing focus: How are string values rendered? Is proper HTML and attribute escaping applied before inserting into the DOM?

2. Information Leakage

While not a vulnerability in the *formatter logic* itself, a formatter running client-side might process sensitive data. If the application hosting the formatter isn't careful, this data could be exposed, e.g., if the formatter logs formatted data to the console, sends it to an analytics service, or saves it client-side insecurely.

Auditing focus: Does the formatter implementation interact with anything other than the display logic? Does the application using the formatter handle the *source* JSON securely?

3. Resource Exhaustion (Denial of Service - DoS)

Maliciously crafted large or deeply nested JSON can cause the formatter to consume excessive memory, CPU, or take an unreasonable amount of time to render, potentially freezing or crashing the browser tab.

{ "a": { "a": { "a": { "a": { /* ... many layers ... */ "a": 1 } } } } }

[ 1, 2, 3, /* ... millions of numbers ... */ ]

Auditing focus: Does the formatter have limits on input size, nesting depth, or processing time? Does it handle large inputs gracefully (e.g., virtual scrolling, lazy rendering)?

4. Prototype Pollution

Less common for basic formatters, but if the formatter involves complex object merging, cloning, or processing logic that recursively handles properties, it could be vulnerable to prototype pollution if using unsafe methods (like recursively copying properties from untrusted input onto target objects) without proper checks.

{ "__proto__": { "isAdmin": true } }

Auditing focus: Does the formatter's internal logic perform deep merging or cloning of untrusted input? Are there checks for `__proto__`, `constructor`, or `prototype` keys?

5. Server-Side Risks (If applicable)

While JSON formatters are usually client-side, if any part of the formatting logic runs on the server (e.g., preprocessing, validation, or server-side rendering), additional risks apply:

• Injection: If the formatter uses helper libraries or shell commands based on JSON values without sanitization (unlikely for standard formatting but possible in custom versions).
• File Path Traversal: If JSON values are ever used to construct file paths.
• Server-side DoS: Similar to client-side, but impacting the server's resources.

Auditing focus: Identify if any part of the formatting process occurs server-side and apply standard server-side input validation and sanitization practices.

Auditing & Mitigation Strategies

1. Strict Output Escaping (Crucial for XSS)

Any JSON value that is displayed as HTML content or an HTML attribute MUST be properly escaped.

• HTML Escaping: Convert characters like `<` to `&lt;`, `>` to `&gt;`, `&` to `&amp;`, `"` to `&quot;`, `'` to `&#x27;` (or `&apos;`), and `/` to `&#x2F;`. This prevents injected HTML tags from being parsed by the browser.
• Attribute Escaping: Similar to HTML escaping, but specifically for values going into HTML attributes (like `src`, `href`, `onerror`). Ensure quotes and other attribute-breaking characters are handled.
• JavaScript Escaping: If JSON values are ever placed inside `<script>` tags (rare for a formatter, but check custom features), they need JavaScript string escaping.

function escapeHtml(unsafe: string): string {
  return unsafe
    .replace(/&/g, "&")
    .replace(/</g, "&lt;")
    .replace(/>/g, "&gt;")
    .replace(/"/g, "&quot;")
    .replace(/'/g, "&#x27;") // Use &#x27; for quotes within attributes
    .replace(/\//g, "&#x2F;"); // Recommended for closing tags within HTML
}

// Vulnerable rendering (BAD!)
// element.innerHTML = `<span class="string">"${jsonValue}"</span>`;

// Secure rendering (GOOD!)
// element.innerHTML = `<span class="string">"${escapeHtml(jsonValue)}"</span>`;

// Using React/Vue/Angular rendering is generally safer as they handle escaping by default,
// but be cautious with "dangerouslySetInnerHTML" or "v-html".

Audit the code path where string values are converted into DOM elements. Look for uses of `innerHTML`, `outerHTML`, `document.write`, or frameworks' equivalents like `dangerouslySetInnerHTML` or `v-html`. Ensure escaping is applied *everywhere* untrusted string data is inserted into the DOM.

2. Implement Resource Limits

To prevent DoS, add checks for excessive size or nesting during parsing or formatting.

• Limit maximum JSON string length.
• Limit maximum parsed object/array size (number of keys/elements).
• Limit maximum nesting depth.
• Implement a timeout for the formatting process.

function formatValue(value: any, currentDepth: number, maxDepth: number): string {
  if (currentDepth > maxDepth) {
    return '... (max depth reached) ...'; // Truncate or show error
  }

  if (typeof value === 'object' && value !== null) {
    if (Array.isArray(value)) {
      // Format array elements recursively, incrementing depth
      // ... value.map(item => formatValue(item, currentDepth + 1, maxDepth)) ...
    } else {
      // Format object properties recursively, incrementing depth
      // ... Object.entries(value).map(([key, val]) => ...)
      // ... formatValue(val, currentDepth + 1, maxDepth) ...
    }
  }
  // ... handle primitives (string, number, boolean, null) with escaping ...
  return formatPrimitive(value); // Ensure primitives are escaped!
}

function formatPrimitive(value: any): string {
    if (typeof value === 'string') {
        // MUST escape HTML here!
        return `<span class="string">"${escapeHtml(value)}"</span>`;
    }
    // ... handle numbers, booleans, null ...
    return String(value); // Or styled span
}

const maxAllowedDepth = 100; // Example limit
// Start formatting from the root
// formatValue(parsedJson, 0, maxAllowedDepth);

Audit the recursive or iterative logic that traverses the JSON structure. Ensure there are checks to break the loop or recursion if configured limits are exceeded.

3. Input Validation (Beyond JSON Spec)

While a standard JSON parser validates the syntax, the *values* might need further validation based on the application's context. For a formatter, this is less about data integrity and more about preventing malformed content that might break the formatter itself (though less common with robust parsers) or consume excessive resources.

Auditing focus: Is the standard `JSON.parse` used? (It's generally safe). If a custom parser is used, is it robust against malformed inputs?

4. Sanitize or Filter Sensitive Data

If the JSON being formatted contains sensitive information (passwords, API keys, PII), the application should ideally remove or mask this data *before* passing it to the formatter, especially if the formatter library might have unknown behaviors or the environment is not fully trusted.

Auditing focus: Does the application *handling* the sensitive JSON ensure it's safe before display? The formatter library itself usually shouldn't be responsible for this, but it's a crucial part of the overall security posture.

5. Use Trusted Libraries

Avoid writing a JSON formatter from scratch unless absolutely necessary and you have significant security expertise. Use well-maintained, widely-used libraries with a good security track record. Popular libraries have likely had more scrutiny and penetration testing.

Auditing focus: Identify the JSON parsing and formatting libraries used. Check their popularity, last update, open issues, and any known vulnerabilities.

6. Fuzz Testing & Edge Cases

Test the formatter with malformed JSON, extremely large values, deeply nested structures, strings containing various HTML/JS injection attempts, unusual unicode characters, etc.

Auditing focus: How does the formatter behave with unexpected or malicious inputs? Does it crash, freeze, or execute unwanted code?

Summary & Best Practices

• Escape Output Religiously: ALWAYS HTML and attribute escape JSON string values before rendering them into the DOM. This is the primary defense against XSS.
• Set Resource Limits: Protect against DoS by limiting depth, size, and processing time.
• Sanitize Sensitive Data Upstream: Clean sensitive data *before* it reaches the formatter.
• Prefer Trusted Libraries: Don't reinvent the wheel; use mature, well-audited formatting libraries.
• Test Thoroughly: Include edge cases and malicious inputs in your testing strategy.
• Minimize Privileges: The environment running the formatter should have minimal necessary permissions.

Auditing a JSON formatter implementation involves reviewing how untrusted JSON data is processed, parsed, and especially how it is rendered into the user interface. By focusing on output escaping and resource handling, you can significantly reduce the risk of common web vulnerabilities.