Cybersecurity glossary
What is Client-Side Prototype Pollution?
Learn what client-side prototype pollution is, how browser JavaScript merges pollute Object.prototype, how gadgets escalate to DOM XSS or privilege bypass in SPAs, and how to prevent it.
Definition
Client-Side Prototype Pollution is a browser JavaScript vulnerability in which untrusted input (URL parameters, JSON, postMessage data, or stored state) modifies Object.prototype so that client-side gadgets inherit attacker-controlled properties, often escalating to DOM-based XSS or unauthorized UI privileges.
Why client-side prototype pollution matters
In the browser, a single polluted property can change how an entire SPA behaves. Client-Side Prototype Pollution typically starts with something mundane—query parsing, config merge, or state hydration—and ends with a gadget that writes attacker HTML, loads a script, or flips a client-only “isAdmin” style flag.
Unlike reflected XSS that needs a classic injection point in markup, pollution abuses JavaScript inheritance so libraries and app code become the injection surface after the prototype is already compromised.
How client-side prototype pollution works
Deliver untrusted structure in-page
Craft URL params, JSON, or messages that include __proto__ or constructor.prototype paths.
Frontend merges into objects
Parsers, deep extend, or recursive assign copy dangerous keys onto Object.prototype.
Gadget reads inherited property
App or library code accesses a property that now exists on every object via inheritance.
Escalate to XSS or privilege
The value hits innerHTML, script URLs, navigation, or client auth/UI checks.
Common browser surfaces
URL / hash parsers
Query strings turned into nested objects without stripping prototype keys.
Deep merge of config JSON
Client fetches or hydrates settings and recursively assigns attacker fields.
DOM XSS gadgets
Polluted transport_url, template, or html properties flow into sink APIs.
SPA privilege flags
Inherited isAdmin / role properties bypass client-only authorization UX.
Prevention that works
| Control | Notes |
|---|---|
| Sanitize during parse/merge | Drop __proto__, constructor, and prototype from URL and JSON object walks |
| Null-prototype state objects | Hydrate client state with Object.create(null) or Map-backed stores |
| Own-property checks | Use Object.hasOwn / hasOwnProperty before trusting config-like fields |
| Safe DOM sinks | Prefer textContent, encoding, or Trusted Types—never raw innerHTML from config |
| Defense-in-depth CSP | Strict CSP and Trusted Types reduce XSS impact if a gadget remains |
| Library upgrades | Patch frontend utilities with known recursive-merge pollution histories |
- Audit URL, hash, and query parsers that build nested objects from user-controlled strings.
- Block dangerous keys in every client-side deep merge and recursive assign path.
- Search for gadgets: property reads that feed innerHTML, insertAdjacentHTML, or script src.
- Prefer null-prototype objects for dictionaries and configuration bags in the browser.
- Add e2e tests that visit pollution URLs and assert Object.prototype remains clean.
- Enforce CSP and consider Trusted Types on DOM XSS-prone surfaces.
- Do not rely on client-only flags for authorization—enforce privileges on the server.
- Retest third-party widgets after upgrades; their merges can reintroduce pollution.
The practical takeaway
Client-Side Prototype Pollution is browser inheritance abuse that turns merge bugs into XSS or SPA privilege gadgets. Sanitize prototype paths at parse time, harden DOM sinks, and remember CSP reduces damage—it does not remove the pollution bug.
Related security terms
Prototype Pollution
The general JavaScript inheritance-abuse class covering both client and server.
Server-Side Prototype Pollution
Node.js counterpart where pollution targets server merges and RCE gadgets.
Cross-Site Scripting (XSS)
The most common high-impact outcome when polluted properties reach DOM sinks.
DOM-Based XSS
XSS that executes entirely in the browser—often the gadget endpoint for CSPP.
Frequently asked questions
What is client-side prototype pollution?
Attacker-controlled data in the browser pollutes Object.prototype. Later frontend code reads a property that now exists via inheritance, and that value is used in a dangerous DOM or logic sink.
How do attackers usually deliver the payload?
Through URL query/hash parameters parsed into objects, JSON fetched or posted into the page, localStorage/session state, or postMessage handlers that deep-merge untrusted objects.
What is a gadget in this context?
Application or library code that reads a property (for example a URL, HTML fragment, or config flag) without checking ownership, then passes it to innerHTML, script loading, or auth UI logic.
Why is this dangerous in SPAs?
Single-page apps share one long-lived JavaScript heap. One polluted prototype can affect many components, routers, and third-party widgets after a single malicious visit.
Does CSP stop client-side prototype pollution?
CSP can reduce some XSS impact by blocking inline or unauthorized scripts, but it does not prevent pollution itself or pure logic/privilege gadgets that never inject markup.
How do you find these bugs?
Probe for pollution via crafted __proto__ parameters, then search sources for property reads that become DOM sinks. Browser DevTools and PP-focused scanners help locate gadgets.
How do you fix client-side prototype pollution?
Sanitize keys during parsing/merging, use null-prototype objects, avoid unsafe deep extend of URL-derived objects, and ensure DOM sinks only use own properties with encoding or Trusted Types.
References
Explore authoritative guidance and frameworks related to client-side prototype pollution.
Explore every security definition
Return to the glossary to search by term, alias, starting letter, or security category.