Prototype Pollution Testing in JavaScript: Attacks and Prevention

JavaScript powers modern web applications, REST APIs, browser-based platforms, and server-side applications built with Node.js. Its flexible object model makes development easier, but it also introduces security risks when applications process untrusted input without proper validation. One important example is Prototype Pollution Testing in JavaScript, which helps security professionals identify weaknesses that allow attackers to modify object prototypes and influence application behavior.

Prototype pollution is particularly important because JavaScript uses prototype-based inheritance. Objects can inherit properties from other objects, including the built-in Object.prototype. If an application allows an attacker to modify these shared properties, unrelated parts of the application may start behaving unexpectedly.

Depending on the application, a successful attack may lead to authorization bypasses, cross-site scripting (XSS), denial of service, or potentially remote code execution in vulnerable server-side environments.

Modern applications frequently rely on third-party JavaScript packages, dynamic configuration objects, JSON processing, and API integrations. These components can introduce unsafe object-handling patterns. Therefore, security teams should include prototype pollution checks in their regular web application penetration testing and secure code review processes.

This guide explains how prototype pollution works, where vulnerabilities commonly occur, how penetration testers can identify them, and which development practices help prevent them.

What Is Prototype Pollution in JavaScript?

Prototype pollution is a security vulnerability that occurs when an attacker can modify properties of a JavaScript object’s prototype through uncontrolled input.

JavaScript uses prototypes to implement inheritance. When an application tries to access a property that does not exist directly on an object, JavaScript searches its prototype chain for that property.

Consider the following example:

const user = {
    username: "saurabh"
};

console.log(user.username);
console.log(user.toString());

The username property belongs directly to the user object. However, toString() is inherited through the prototype chain.

This behavior becomes dangerous when an application allows untrusted input to modify shared prototypes.

For example:

Object.prototype.isAdmin = true;

const user = {
    username: "guest"
};

console.log(user.isAdmin); // true

The application never assigned isAdmin to the user object. However, the property is available because it was added to Object.prototype.

In a real application, similar behavior could affect authorization checks, configuration settings, and other security-sensitive operations.

The vulnerability is commonly associated with CWE-1321: Improperly Controlled Modification of Object Prototype Attributes.

Why Is Prototype Pollution Testing Important?

Prototype pollution testing helps identify unsafe object manipulation before attackers can use it to affect application functionality.

The vulnerability can be difficult to recognize because the initial issue may appear to be an ordinary input-handling problem. A vulnerable function might accept JSON data, merge configuration objects, or dynamically assign properties without validating their names.

Security testing is important for several reasons.

1. Authorization Bypass

Applications sometimes use object properties to determine whether a user can access a particular resource.

For example:

function checkAccess(user) {
    if (user.isAdmin) {
        return "Access granted";
    }

    return "Access denied";
}

If the application relies on an inherited property instead of checking whether isAdmin belongs to the user object, prototype pollution could influence the access decision.

This is particularly dangerous when authorization logic assumes that missing properties are always false.

2. Cross-Site Scripting (XSS)

Client-side prototype pollution can sometimes be combined with vulnerable JavaScript functions that process DOM elements or HTML content.

For example, if an application reads an inherited property and uses it to configure an iframe or another HTML element, an attacker may be able to influence the resulting behavior.

The actual impact depends on the available source, the affected property, and the application’s execution context.

3. Remote Code Execution

Server-side prototype pollution can have serious consequences in vulnerable Node.js applications.

If polluted properties reach sensitive functionality, such as child-process configuration or other dangerous execution paths, an attacker may be able to influence server-side operations.

However, prototype pollution does not automatically provide remote code execution. An exploitable gadget and suitable application behavior are generally required.

4. Application Availability

Unexpected properties can break application logic, interfere with configuration handling, or cause runtime exceptions.

In some cases, this can result in application instability or denial of service.

How Does Prototype Pollution Work?

To understand the vulnerability, penetration testers should understand three important concepts: JavaScript prototypes, pollution sources, and exploitation gadgets.

Understanding the JavaScript Prototype Chain

Every ordinary JavaScript object normally inherits from Object.prototype, unless it has been explicitly created without a prototype or assigned a different prototype.

For example:

const employee = {
    name: "Alex"
};

console.log(Object.getPrototypeOf(employee));

The returned prototype is normally Object.prototype.

When JavaScript accesses a property, it checks the object itself first. If the property is missing, it searches the prototype chain.

This inheritance mechanism is useful for application development, but unsafe modification of shared prototypes can affect multiple objects.

Understanding Pollution Sources

A pollution source is a function or input-processing mechanism that allows attacker-controlled property names to influence object modification.

Common sources include:

• Recursive object merge functions.
• JSON configuration processing.
• Query-string parsers.
• Dynamic property assignment.
• Deep cloning utilities.
• Nested object update functions.
• Third-party JavaScript libraries.

For example, consider this unsafe function:

function updateObject(target, key, value) {
    target[key] = value;
}

The function directly uses the supplied key without validating it.

When applications perform nested assignments using attacker-controlled property paths, special property names may allow access to prototype-related objects.

Understanding Exploitation Gadgets

A gadget is an existing application function that reads or uses a property influenced by prototype pollution.

A vulnerability becomes more dangerous when polluted properties reach sensitive operations.

Examples of potential gadgets include:

• HTML element configuration.
• Fetch request options.
• Authorization checks.
• Template rendering functions.
• Child-process configuration.
• Application settings.
• File-processing functionality.

Finding a pollution source is only the first part of testing. A professional penetration tester should also determine whether the affected property influences a security-sensitive operation.

Common Prototype Pollution Attack Vectors

Several JavaScript patterns can introduce prototype pollution vulnerabilities.

1. The __proto__ Property

The __proto__ property is one of the most recognized prototype pollution entry points.

It provides access to an object’s prototype through a legacy accessor.

Consider this example:

const payload = JSON.parse(
    '{"__proto__":{"testProperty":"polluted"}}'
);

const target = Object.assign({}, payload);

console.log(target.testProperty);

The JSON parser creates an object containing an own property named __proto__. During the assignment, the target object’s prototype can be changed.

This example demonstrates why developers should carefully inspect object-merging operations.

2. The constructor.prototype Property

Disabling __proto__ does not completely prevent prototype pollution.

JavaScript also provides access to constructor and prototype properties.

An unsafe nested property assignment can expose the same underlying risk:

const target = {};

const path = ["constructor", "prototype", "testProperty"];

let current = target;

for (const key of path.slice(0, -1)) {
    current = current[key];
}

current[path[path.length - 1]] = "polluted";

console.log(({}).testProperty);

The example demonstrates how an unsafe property path can reach Object.prototype.

This is why filtering only __proto__ is not a complete security solution.

3. Recursive Merge Functions

Recursive merge functions combine two or more objects, including their nested properties.

They are common in configuration management and application development.

Consider:

function mergeObjects(target, source) {
    for (const key in source) {
        if (typeof source[key] === "object" &&
            source[key] !== null) {

            target[key] = target[key] || {};

            mergeObjects(target[key], source[key]);

        } else {
            target[key] = source[key];
        }
    }

    return target;
}

This implementation does not validate property names or restrict inherited properties.

Consequently, an attacker-controlled nested property may reach a prototype-related object.

Developers should avoid writing generic merge utilities without strict property validation and appropriate safeguards.

4. Query Parameter Processing

Web applications frequently convert URL parameters into JavaScript objects.

For example:

https://example.com/profile?name=alex&role=user

A query-string parser may convert these values into an object.

Problems arise when the parser accepts nested property paths without safely handling special property names.

Security testers should inspect how URL parameters, nested keys, and decoded values are processed.

Types of Prototype Pollution Vulnerabilities

Prototype pollution is generally divided into two major categories.

Client-Side Prototype Pollution

Client-side prototype pollution occurs in the browser when application JavaScript modifies object prototypes using attacker-controlled input.

Common sources include:

• URL query parameters.
• URL fragments.
• JSON data.
• Client-side configuration.
• DOM-based input processing.
• Vulnerable JavaScript dependencies.

A successful client-side attack may influence browser-side functionality and, in certain cases, lead to DOM-based XSS.

Tools such as Burp Suite and DOM Invader can help identify potential sources and gadgets.

Server-Side Prototype Pollution

Server-side prototype pollution occurs in JavaScript applications running on environments such as Node.js.

Unlike browser-side attacks, pollution may affect objects used by backend services, API handlers, and application processes.

Common sources include:

• API request bodies.
• JSON parsing.
• User profile updates.
• Configuration merging.
• Third-party packages.
• Dynamic object construction.

Server-side testing requires additional caution because prototype modifications may remain active throughout the lifetime of the Node.js process.

A successful test can affect subsequent requests and potentially disrupt the service.

How to Perform Prototype Pollution Testing

A structured testing methodology helps penetration testers identify vulnerabilities without unnecessarily affecting application functionality.

Testing should only be performed against applications for which you have explicit authorization.

Step 1: Identify JavaScript-Based Functionality

Start by understanding how the application handles user-controlled data.

Look for functionality that accepts or modifies:

• User profile information.
• Application settings.
• Search filters.
• JSON request bodies.
• Nested configuration values.
• API parameters.
• User preferences.

Use browser developer tools or an intercepting proxy to inspect requests and responses.

Pay particular attention to endpoints that accept nested JSON objects.

Step 2: Inspect Object Manipulation Functions

During source code review, search for potentially unsafe JavaScript patterns.

Examples include:

Object.assign()

for (const key in source)

target[key] = value;

obj[path[0]][path[1]] = value;

These patterns are not automatically vulnerable. Their security depends on how the application validates keys, handles prototypes, and processes untrusted data.

Also review third-party dependencies that provide deep merge, object cloning, or property-setting functionality.

Step 3: Test Special Property Names

Inspect whether the application safely handles prototype-related property names.

The most important names to review are:

__proto__
constructor
prototype

Use harmless test values in an authorized environment.

For example, a test JSON structure might contain:

{
  "profile": {
    "displayName": "security-test"
  },
  "settings": {
    "theme": "dark"
  }
}

Then inspect how the application handles unexpected nested property names.

Do not assume that receiving an HTTP 200 response proves that the input was processed safely.

Step 4: Check for Prototype Modification

For client-side testing, browser developer tools can help determine whether a property has been added to a shared prototype.

For example, in a controlled test environment:

console.log(
    Object.prototype.hasOwnProperty("testProperty")
);

The expected result is false if the property has not been introduced.

After sending a harmless test through the suspected input-processing function, inspect the result again.

A change from false to true may indicate that the prototype has been modified.

Always perform this check in an isolated environment and restore the application state afterward.

Step 5: Identify Potential Gadgets

Once a pollution source is identified, investigate how the affected property is used elsewhere.

Review functions that process:

• Request configuration.
• HTML attributes.
• Template variables.
• User permissions.
• File operations.
• Backend process options.

For example, an application may construct a request configuration object using inherited properties.

This could allow polluted properties to influence the HTTP method or request body.

The important testing objective is to determine whether the polluted property reaches a sensitive application operation.

Step 6: Evaluate the Security Impact

Not every prototype pollution finding has the same severity.

Evaluate:

• Whether an attacker can control the pollution source.
• Whether the modification affects a shared prototype.
• Whether the property is consumed by application code.
• Whether authentication is required.
• Whether another user can be affected.
• Whether the behavior can be reproduced.
• Whether the issue can be chained with another vulnerability.

Document the evidence and distinguish confirmed impact from theoretical exploitation possibilities.

Real-World Security Scenarios

Prototype pollution can affect different types of JavaScript applications.

Scenario 1: E-Commerce Application

Imagine an e-commerce platform that stores user preferences in JavaScript objects.

The application merges incoming preferences with default configuration values.

If the merge function does not validate nested property names, an attacker may be able to influence properties inherited by other objects.

If those properties are later used in payment or checkout configuration, the application may behave unexpectedly.

The security team should investigate the source of the input, the merge operation, and every sensitive function that consumes the resulting configuration.

Scenario 2: Admin Dashboard

Consider an administrative dashboard that checks whether a user has administrator privileges using a property such as isAdmin.

If the application relies on inherited properties instead of verifying that the property exists directly on the user object, prototype pollution could interfere with access-control decisions.

Authorization should always be enforced using trusted server-side identity and permission data, not client-controlled object properties.

Scenario 3: Node.js API

A Node.js API may accept JSON data to update customer profiles.

The backend merges the submitted data into an existing user object.

If the merge logic is vulnerable, specially crafted nested properties may influence objects used by other backend functions.

This could potentially result in authorization issues, application instability, or more serious consequences if exploitable gadgets exist.

These scenarios illustrate why prototype pollution should be considered during both frontend and backend security assessments.

Tools Used for Prototype Pollution Testing

Penetration testers can use several tools to identify prototype pollution sources and understand their impact.

1. Burp Suite

Burp Suite is useful for intercepting and modifying HTTP requests.

Security testers can use it to:

• Inspect JSON request bodies.
• Modify nested parameters.
• Test API endpoints.
• Replay requests.
• Compare application responses.
• Investigate input-processing behavior.

It is particularly useful when testing server-side JavaScript applications and API endpoints.

2. DOM Invader

DOM Invader is a browser-based testing feature available in Burp Suite’s built-in browser.

It helps security researchers investigate client-side sources, prototype pollution behavior, and potential DOM-based gadgets.

It can automate parts of the discovery process and make client-side testing more efficient.

3. Browser Developer Tools

Chrome and Firefox developer tools provide access to JavaScript execution, object inspection, network requests, and runtime debugging.

They help testers:

• Inspect JavaScript objects.
• Examine prototype chains.
• Review loaded scripts.
• Monitor DOM changes.
• Debug suspicious functions.

4. Static Code Analysis

Static analysis helps identify unsafe object manipulation without requiring the application to execute every code path.

Review custom merge functions, dynamic property assignments, and dependencies that process untrusted object keys.

Dependency auditing is also important because vulnerable third-party packages may introduce risks even when the application’s own code appears secure.

5. Node.js Testing Environment

A controlled Node.js environment allows testers to reproduce server-side behavior safely.

Use isolated processes, test data, and disposable environments when investigating prototype modification.

Never experiment with potentially persistent prototype changes on production systems without an approved testing plan.

How to Prevent Prototype Pollution

Developers should combine secure coding practices, input validation, dependency management, and runtime protections.

1. Validate User Input

Validate incoming JSON and other user-controlled data against an explicit schema.

Reject unexpected properties whenever possible.

For example, a schema validator can restrict which fields an API accepts and define the expected data types.

Validation should also reject dangerous property names such as:

__proto__
constructor
prototype

Filtering should happen before unsafe property assignment or recursive merging.

2. Use Object.create(null)

When an application needs a dictionary-like object, developers can create an object without a prototype.

const userSettings = Object.create(null);

userSettings.theme = "dark";

console.log(
    Object.getPrototypeOf(userSettings)
); // null

This prevents the object from inheriting properties from Object.prototype.

However, developers should consider compatibility requirements when passing null-prototype objects to other APIs.

3. Prefer Map and Set

For key-value storage, JavaScript’s Map is often a safer alternative to ordinary objects.

const userRoles = new Map();

userRoles.set("alex", "admin");
userRoles.set("john", "user");

console.log(userRoles.get("alex"));

A Map stores entries separately from object properties and avoids the usual prototype inheritance behavior for dictionary keys.

4. Use Object.hasOwn()

Avoid relying on inherited properties for security-sensitive decisions.

Instead of:

if (user.isAdmin) {
    console.log("Admin access");
}

Use an explicit own-property check:

if (
    Object.hasOwn(user, "isAdmin") &&
    user.isAdmin === true
) {
    console.log("Admin access");
}

This prevents an inherited property from being mistaken for a property explicitly assigned to the user object.

It does not replace proper server-side authorization.

5. Avoid Unsafe Recursive Merging

Do not recursively merge untrusted objects without strict validation.

Use well-maintained libraries, review their security history, and ensure that dangerous property paths are rejected.

Also avoid assuming that a particular object-copying method is universally safe.

For example, Object.assign() and object spread behave differently when handling an own __proto__ property. Object spread does not invoke the legacy prototype setter in the same way as Object.assign(), but it is not a complete solution to every prototype pollution scenario.

6. Use Node.js Runtime Protections

Node.js supports the following runtime option:

node --disable-proto=delete app.js

This removes the legacy Object.prototype.__proto__ accessor.

It reduces one possible attack path but does not eliminate prototype pollution because alternative paths, including constructor.prototype, may remain accessible.

7. Keep Dependencies Updated

Third-party packages are a common part of modern JavaScript development.

Developers should regularly:

• Review dependency security advisories.
• Update vulnerable packages.
• Remove unused dependencies.
• Audit deep merge utilities.
• Monitor package maintenance.
• Test security fixes before deployment.

Dependency management should be part of the application’s regular security maintenance process.

Best Practices for Penetration Testers

A professional prototype pollution assessment should focus on both vulnerability discovery and practical impact.

Consider the following checklist:

1. Identify all endpoints that accept nested JSON.
2. Inspect URL parameters and client-side configuration.
3. Review recursive merge and object assignment functions.
4. Check handling of __proto__, constructor, and prototype.
5. Identify whether the affected prototype is shared or local.
6. Look for sensitive properties consumed by application functions.
7. Test client-side and server-side behavior separately.
8. Use isolated environments for persistent server-side tests.
9. Evaluate possible XSS, authorization, and availability impacts.
10. Provide reproducible evidence and remediation guidance.

A good penetration testing report should explain the vulnerable input, affected function, observed behavior, security impact, and recommended fix.

Avoid reporting every unsafe-looking JavaScript function as a confirmed vulnerability. Demonstrate that attacker-controlled input can actually influence the relevant prototype or application behavior.

How to Report a Prototype Pollution Vulnerability

Clear reporting helps developers understand and fix the issue efficiently.

A professional vulnerability report should contain the following sections.

Vulnerability Title

Prototype Pollution in JavaScript Object Merge Function.

Vulnerability Description

Explain how untrusted input reaches an object manipulation function and how the function handles prototype-related properties.

Affected Endpoint

Include the affected API endpoint or application functionality.

Steps to Reproduce

Provide the minimum steps required to reproduce the behavior in an authorized testing environment.

Proof of Concept

Include harmless test input and relevant request or response evidence.

Security Impact

Explain the confirmed consequences, such as unauthorized property inheritance, configuration manipulation, or an exploitable gadget.

Remediation

Recommend input validation, safe object creation, secure merge operations, and appropriate runtime protections.

References

Include relevant OWASP guidance, MDN documentation, and CWE classifications.

Learning and Career Opportunities

Prototype pollution testing is a useful skill for professionals interested in web application penetration testing, application security, and JavaScript security research.

Understanding this vulnerability requires knowledge of:

• JavaScript fundamentals.
• Object inheritance and prototype chains.
• HTTP requests and JSON.
• REST API security.
• Burp Suite.
• Browser developer tools.
• Node.js application architecture.
• Secure coding practices.

Beginners can start by learning JavaScript object handling before moving into practical vulnerability testing.

Hands-on practice is particularly useful. Working through intentionally vulnerable applications helps security learners understand how pollution sources, gadgets, and exploitation paths work together.

You can explore cyber security labs to strengthen practical testing skills and build experience with real-world vulnerability scenarios.

For structured learning, cyber security training can help learners develop the technical foundation required for penetration testing and application security roles.

Future Scope of Prototype Pollution Testing

JavaScript continues to play an important role in frontend development, backend services, serverless applications, and modern web frameworks.

As applications become more dependent on third-party packages and complex configuration handling, secure object manipulation will remain an important part of application security.

Several areas deserve continued attention:

JavaScript Dependency Security

Applications frequently depend on external libraries for data processing and configuration management. Security researchers will continue to examine how vulnerable dependencies introduce prototype pollution risks.

Server-Side JavaScript Security

The growing use of Node.js in APIs, microservices, and cloud environments makes server-side prototype pollution an important testing area.

Automated Security Testing

Static analysis, dynamic testing, and browser-based security tools can help discover unsafe property handling and identify potential exploitation gadgets.

Secure Software Development

Development teams are increasingly expected to consider security during the software development lifecycle rather than treating penetration testing as a final step.

Understanding prototype pollution helps developers and security professionals build more resilient JavaScript applications.

Conclusion

Prototype pollution is an important JavaScript security vulnerability that can affect both browser-based applications and server-side Node.js environments. It occurs when untrusted input reaches unsafe object manipulation functionality and allows an attacker to modify prototype-related properties.

However, identifying a pollution source is only the beginning. Security professionals must also investigate how the affected properties are consumed and whether they can influence sensitive application functionality.

Effective protection requires strict input validation, safe object handling, secure dependency management, and appropriate runtime defenses. Penetration testers should also distinguish between a theoretical weakness and a vulnerability with demonstrated security impact.

Whether you are a developer, security analyst, or penetration tester, understanding prototype pollution will strengthen your knowledge of modern JavaScript application security.

At PentestHint, we encourage practical security learning, responsible vulnerability research, and continuous improvement. Explore our security consulting resources and practical learning opportunities to strengthen your application security skills.

Frequently Asked Questions (FAQs)

1. What is prototype pollution in JavaScript?

Prototype pollution is a JavaScript vulnerability that occurs when an attacker modifies properties of an object’s prototype through unsafe input handling. These properties may then be inherited by other objects and influence application behavior.

2. Is prototype pollution a critical vulnerability?

Its severity depends on the application’s implementation and the available exploitation paths. A pollution source alone may have limited impact, while a vulnerability chained with authorization bypass, XSS, or remote code execution can be much more serious.

3. What are the common prototype pollution payload properties?

The most commonly investigated property names are __proto__, constructor, and prototype. Their impact depends on how the application processes nested properties and performs object assignments.

4. How can I test for prototype pollution?

Start by identifying endpoints and JavaScript functions that process untrusted nested objects. Inspect special property names, review object manipulation functions, and check whether controlled input modifies a prototype or influences sensitive application behavior.

5. What is the difference between client-side and server-side prototype pollution?

Client-side prototype pollution affects JavaScript executing in a user’s browser. Server-side prototype pollution affects JavaScript environments such as Node.js, where the consequences may extend to backend services and subsequent requests.

6. Can prototype pollution lead to remote code execution?

Yes, in certain vulnerable server-side applications. If prototype pollution reaches an exploitable gadget that influences command execution or process configuration, it may lead to remote code execution. However, this is not an automatic consequence of every prototype pollution vulnerability.

7. Which tools are useful for prototype pollution testing?

Burp Suite, DOM Invader, browser developer tools, static analysis tools, and isolated Node.js testing environments are useful for identifying and investigating prototype pollution vulnerabilities.

8. How can developers prevent prototype pollution?

Developers should validate incoming data, reject dangerous property names, avoid unsafe recursive merges, use Object.create(null) or Map where appropriate, check own properties with Object.hasOwn(), and maintain secure third-party dependencies.