Why Google, Facebook, and Canva Inject “Junk Characters” into API Responses

If you have ever poked around the Network tab in your browser’s Developer Tools while using services from tech giants like Google, Meta (Messenger), or Canva, you might have stumbled upon something bizarre.

Right at the beginning of their JSON API responses, they often insert a few strange, invalid characters (like )]}',), or even an infinite loop (like for(;;);).

Why on earth do they do this? Doesn’t this force their own frontend developers to waste a step stripping out these “junk characters” before they can actually parse the JSON?

As it turns out, this isn’t a bug or a legacy mistake. It is a brilliant, proactive security technique designed to neutralize a classic web vulnerability known as JSON Hijacking.

1. How JSON Hijacking Works

To understand the fix, we first need to look at the flaw. Normally, web browsers enforce the Same-Origin Policy (SOP). This policy prevents a malicious website (e.g., attacker.com) from directly reading data from another website (e.g., google.com) using modern methods like fetch() or XMLHttpRequest.

However, historically, the <script> tag was a major exception. You can embed a script from any domain into your website, and the browser will gladly execute it without SOP blocking it.

Capitalizing on this loophole, attackers devised a clever exploit:

1. The Bait: An attacker sets up a malicious website and lures a victim to it. The victim is already logged into their Google account in another tab.
2. Overriding the Array Constructor: On the malicious page, the attacker overrides the default JavaScript Array constructor (or Object.prototype setters) to spy on any new arrays being created.
3. The Trap: The attacker inserts a <script> tag on their page with the src attribute pointing directly to a private Google API that returns sensitive user data.
4. The Theft: Because browsers automatically attach login cookies to resource requests, Google happily returns the data. If the API returns a valid JSON array (e.g., [{"secret": "data"}]), the browser interprets it as a valid JavaScript file and executes it. This execution triggers the hijacked Array constructor, allowing the attacker to read the sensitive data out of the array.

“Wait, wouldn’t CORS block this?”

Many developers assume Cross-Origin Resource Sharing (CORS) handles this security layer. However, CORS only applies to requests made via standard AJAX tools like fetch() or XHR. A standard <script> tag bypasses CORS entirely.

2. How the Tech Giants Smash the Exploit

To kill this vulnerability right at the doorstep, engineers at major tech companies chose to deliberately break the syntax validity of the script execution:

• Google’s Approach: They prepend characters like )]}', to the response. If an attacker tries to load this API via a <script> tag, the browser tries to execute it, hits a blatant Syntax Error instantly, and crashes the script execution before it ever reads the data.
• Facebook & Canva’s Approach: They prepend an infinite loop like for(;;);. If an attacker embeds it in a <script> tag, the browser tab hangs indefinitely and never reaches the sensitive payload hidden underneath.

Meanwhile, on their official applications, their developers simply fetch the data as a raw string, slice off the protective prefix, and then safely run JSON.parse() on the clean JSON payload.

3. Past vs. Present: Is JSON Hijacking Still a Threat?

In reality, JSON Hijacking is no longer a massive threat on modern web browsers. Browsers have evolved and grown significantly smarter.

The exact trick of overriding the global Array constructor or tampering with Object.prototype to steal JSON arrays was patched by major browsers like Chrome, Safari, and Edge over a decade ago (around the late 2000s/early 2010s). Today, modern browsers parse JSON arrays natively at a deeper root level without invoking the exposed JavaScript environment.

So why do tech giants still keep these seemingly “useless” lines of code in their systems?

The answer lies in the ultimate security mindset: Defense-in-Depth.

4. The Lesson of Defense-in-Depth

The golden rule of systems security is: Never outsource the life and safety of your data entirely to a third party (in this case, the user’s browser).

• The Outlier User: Can you guarantee with 100% certainty that a user isn’t accessing your site through a deeply outdated browser built into an old Smart TV or a legacy operating system?
• The Zero-Day Threat: Who is to say a malicious actor won’t discover a brand-new, zero-day vulnerability tomorrow that bypasses modern browser protections?

Instead of relying on the hope that a user’s browser is up-to-date and flawless, Google, Meta, and Canva choose to take control of the risk themselves. Even if an attacker uncovers an entirely new way to trick a browser into pulling data via a <script> tag, they will immediately crash into a brick wall of syntax errors or infinite loops.

Conclusion

Those seemingly random characters or strange infinite loops are proof of world-class engineering foresight. They serve as a great reminder to every developer: When it comes to protecting user data, over-engineering your security layers is never a waste of time. Building proactive, defensive measures into your system ensures safety, regardless of what vulnerabilities might emerge tomorrow.