What Is Prototype Pollution in JavaScript?

Prototype pollution is a JavaScript weakness in which untrusted input changes properties on an object prototype. Because many later objects inherit from that prototype, one write can influence unrelated application logic.

The vulnerability usually needs two ingredients: a source that accepts attacker-controlled property names and a sink that writes those names into an object graph. Common sinks include recursive merge utilities, configuration overlays, deserializers and helpers that set nested paths from strings.

How Prototype Pollution Happens

Applications often accept JSON, form data or query parameters and merge them into defaults. If a helper walks each supplied key without treating prototype-related names as special, the write can escape the intended data object and affect inherited behavior.

// Risky pattern: structure is controlled by input
for (const [key, value] of Object.entries(input)) {
  deepSet(options, key, value); // unsafe if key paths are not constrained
}

The important problem is not JSON itself. It is allowing untrusted property paths to control where writes occur. A framework patch may close one known path while a custom merge helper leaves another open.

Where Prototype Pollution Appears in APIs and Node.js

Review both direct dependencies and application-specific helpers. Prototype pollution has historically appeared in generic utility packages because they are reused across many code paths.

Why Prototype Pollution Can Become a Security Vulnerability

Impact depends on which inherited properties the application later trusts. Pollution may alter authorization flags, request options, sanitizer behavior, template configuration or other security-relevant defaults. In some environments, a polluted property can become part of a second vulnerability chain.

Do not assume every prototype pollution bug leads to remote code execution. Severity should be based on the reachable gadgets and security-sensitive behavior in the affected application.

Source, Pollution and Gadget: How to Assess Exploitability

A useful prototype-pollution review separates three questions. First, is there a source that lets untrusted input control a property name or nested path? Second, is there a pollution sink that writes that path into an object graph in a way that can reach a prototype? Third, is there a security-relevant gadget that later reads an inherited property and changes behavior because of it?

This distinction matters because detecting a dangerous key in a request is not the same as proving impact. Some applications reject it before assignment; others write only into null-prototype dictionaries; and some can be polluted but have no reachable gadget that affects authorization, code execution, request options or another security boundary. Triage should therefore prove the data flow from controllable key to sink to security-relevant use.

Prototype Pollution Prevention in JavaScript

OWASP recommends avoiding object-literal dictionaries when untrusted keys are expected. Map and Set separate entries from object prototype properties, and Object.create(null) creates an object without an inherited prototype.

const attributes = new Map();
attributes.set(userKey, userValue);

const safeDictionary = Object.create(null);
safeDictionary[validatedKey] = value;

• Validate incoming objects against an explicit schema and reject unexpected properties.
• Reject dangerous key/path segments such as __proto__, constructor and prototype before any nested write.
• Avoid generic recursive merge or set-by-path helpers for attacker-controlled data unless their behavior is proven safe.
• Prefer Map/Set or null-prototype dictionaries when keys are data rather than application properties.
• Keep dependencies current and review prototype-pollution advisories for parsing/utility packages.
• Use Node.js prototype-related hardening flags only as defense in depth; they do not remove every pollution path.

JavaScript and Node.js Hardening Beyond Input Filtering

Schema validation should reject unexpected object properties wherever the API contract does not require them. For dictionary-like data with attacker-controlled keys, prefer Map or objects created with Object.create(null). Deep-merge and path-setting utilities should explicitly reject prototype-related path components rather than relying on one blacklist at the HTTP boundary.

Dependency upgrades are equally important because generic object-manipulation utilities are reused across many call paths. Search both direct and transitive dependencies for known prototype-pollution fixes, then review custom merge helpers that scanners may not recognize. Freezing global prototypes can sometimes detect or limit mutation in controlled code, but it can break legitimate libraries and is not a substitute for fixing the unsafe write.

For Node.js deployments, runtime options that restrict legacy prototype mutation can be useful defense in depth where compatibility permits. Treat these controls as containment: application code should still prevent untrusted property paths from reaching unsafe assignment primitives.

JSON Parsing vs Unsafe Object Merging

Receiving a JSON object that contains a suspicious property name does not automatically mean the JavaScript prototype has been polluted. The security boundary is crossed when application code later copies, merges, assigns or resolves attacker-controlled property paths in a way that can reach an inherited prototype.

This distinction is useful during code review. JSON.parse() can create an ordinary own property named __proto__; the dangerous behavior may appear later when that parsed object is passed to an unsafe merge or assignment primitive. OWASP specifically recommends avoiding untrusted recursive merges and set-by-path helpers, using Map or null-prototype objects where appropriate, and treating Node.js prototype-disabling flags as defense in depth rather than a complete fix.

Review the entire data flow instead of filtering one key at the HTTP edge. A dangerous path may be reconstructed from multiple parameters, imported configuration, message-queue data or nested objects after the original request has already passed validation.

Prototype Pollution vs Mass Assignment

Prototype pollution and mass assignment can both begin with attacker-controlled object data, but they cross different security boundaries. Prototype pollution modifies or influences an inherited JavaScript prototype. Mass assignment occurs when external object fields are copied into a domain model and unexpectedly change properties the caller should not control.

The same endpoint can contain both weaknesses. For example, accepting arbitrary nested JSON into a generic merge helper can expose prototype paths while also allowing unauthorized domain properties. Test and remediate the two data flows separately.

Code Review and Detection Checklist

Search code for deep merge calls, dynamic property assignment, path setters and places where request objects become configuration. Then trace the property names, not just the values. A value can be perfectly validated while its key still changes application structure.

• Trace property names from query strings, JSON bodies, headers and persisted user-controlled objects.
• Inventory helpers that recursively copy objects or interpret dotted/bracketed paths.
• Test authorization and security defaults when inherited properties unexpectedly exist.
• Add regression tests for rejected dangerous property names at every parser and merge boundary.
• Monitor dependency updates for libraries that manipulate nested objects.

Prototype Pollution and API Security

APIs commonly transform structured client input into JavaScript objects, which makes object-shape validation particularly important. Treat request schemas as a security control: reject unknown properties when the endpoint does not need them, normalize expected types and avoid merging request bodies directly into trusted server-side objects.

Related Ammune reading: API security testing vs runtime monitoring and Mass assignment API vulnerability.

Where Runtime API Visibility Helps

Ammune can complement secure coding by surfacing unusual request shapes, repeated suspicious property names and API behavior associated with exploitation attempts. The underlying fix remains in application code and dependency configuration: runtime monitoring cannot make an unsafe merge primitive safe.

Prototype Pollution Defense Checklist

• Use schemas that reject unexpected object properties.
• Block prototype-related key segments before dynamic writes.
• Replace unsafe dictionaries with Map/Set or null-prototype objects where practical.
• Avoid merging raw request bodies into configuration/state.
• Patch vulnerable JavaScript utility and parser dependencies.
• Add unit and integration tests for prototype-pollution regressions.
• Review authorization logic for reliance on inherited defaults.
• Monitor production APIs for anomalous object structures and exploitation attempts.

Frequently Asked Questions

Primary References