Prototype pollution is a vulnerability that occurs when an attacker manipulates the prototype of an object to introduce malicious properties or methods. This can lead to unintended behaviour or security breaches in the application.
Privilege Escalation: As shown above, if an application checks if (user.isAdmin), an attacker can make themselves an admin globally.
Denial of Service (DoS): An attacker can overwrite built-in methods like toString or valueOf with a value that isn't a function, causing the entire application to crash the next time that method is called.
Remote Code Execution (RCE): If the polluted property is used as a configuration for a system command (like a file path or a template engine setting), the attacker can execute arbitrary code on the server.
Bypassing Input Validation: Attackers can inject properties that bypass security filters or sanitizers that rely on checking object properties.
Use Object.create(null): If you are creating an object to store data (like a map or a cache), create it without a prototype. This makes it immune to pollution.
Validate Keys: Always check if the key being processed is proto, constructor, or prototype and block it.
Freeze the Prototype: In your main entry file, you can freeze the base prototype to prevent any changes at runtime.
Use Map instead of Object: For collections of dynamic keys, use the Map data structure. It does not use the prototype chain for its entries, making it safe from this specific attack.
If you receive a JSON payload that will be merged into a plain object using Object.assign, what could go wrong if the payload contains a proto property?
How would you prevent prototype pollution when you need to deep‑merge user‑provided configuration objects?
We have a Node.js microservice that uses lodash's merge to combine request bodies into a settings object. Suddenly some users can read other users' data. Walk me through how prototype pollution could cause this and how you'd debug it.
When adding a new feature that stores user preferences in a shared in‑memory cache, what trade‑offs would you consider to avoid prototype pollution while keeping performance high?
Design a library that safely merges arbitrary objects from untrusted sources. What patterns would you use to guard against prototype pollution, and how would you test it at scale?
Our platform runs third‑party plugins that may extend objects. How would you architect a sandbox or isolation layer to ensure prototype pollution cannot affect the core runtime?
Across multiple services we have a shared internal SDK that many teams import. How would you lead a migration to eliminate prototype‑pollution risks without breaking existing integrations?
What long‑term governance processes would you put in place to detect and prevent prototype pollution in a large codebase that includes many open‑source dependencies?