Client-Side Security: Prototype Pollution & postMessage

Why Client-Side JavaScript Bugs Matter

Not every serious web vulnerability lives on the server. Two of the most consequential client-side bug classes — prototype pollution and postMessage misuse — can lead directly to XSS, account takeover, or data leakage, entirely through JavaScript running in the victim's own browser.

Prototype Pollution: Corrupting the Prototype Chain

Every JavaScript object inherits properties through its prototype chain. Object.prototype sits at the root of nearly every object's chain — which means if an attacker can add or overwrite a property on Object.prototype itself, that property appears to exist on every object in the application, even ones that never explicitly define it.

A classic vulnerable pattern is a recursive merge/clone function that doesn't block the special key __proto__:

function merge(target, source) {
  for (let key in source) {
    if (typeof source[key] === 'object') {
      merge(target[key], source[key]);   // no check for "__proto__"
    } else {
      target[key] = source[key];
    }
  }
}

merge({}, JSON.parse('{"__proto__": {"isAdmin": true}}'));
// Every object in the application now has isAdmin: true

From Pollution to Impact: The "Gadget"

Pollution alone doesn't do anything visible — it needs a gadget: existing application code that reads a property assuming it was never set, and behaves unsafely when it suddenly is. A common gadget pattern: a templating or config-reading function that checks if (options.debug) and injects debug HTML — an attacker who pollutes Object.prototype.debug = true can turn that harmless-looking check into stored or reflected XSS across the entire application, even in code paths that never directly touch attacker input.

postMessage: Cross-Origin Messaging, Done Wrong

window.postMessage() lets two windows/iframes from different origins communicate safely — but only if both sides validate the message's origin correctly.

window.addEventListener('message', (event) => {
  // VULNERABLE: no origin check at all
  document.getElementById('content').innerHTML = event.data.html;
});

Without checking event.origin against an explicit allowlist, this listener accepts a message — and injects its HTML directly into the page — from any origin on the internet that can get the victim to open a malicious page with a hidden iframe/popup referencing the vulnerable page.

window.addEventListener('message', (event) => {
  if (event.origin !== 'https://trusted-partner.example.com') return;
  // now safe to process event.data
});

Blast Radius: Client-Side-Only vs Server-Reachable

A bug confined entirely to client-side JavaScript still requires getting the victim to load a malicious page (unlike, say, a server-side SQL injection reachable directly by an attacker) — but the impact once triggered (arbitrary script execution in the victim's authenticated session) is functionally equivalent to XSS, and should be treated with the same severity.

Mitigations

Common Pitfalls

• Blocking only the literal string __proto__ while missing constructor.prototype, an equivalent path to the same object
• Validating the message's content but never checking event.origin at all
• Assuming a client-side-only bug is automatically lower severity than a server-side one, without considering the actual impact once triggered