Home / Knowledge hub / Prototype pollution
Knowledge hub
Prototype pollution
Changing the base object every JavaScript object inherits from, through user input.
What it means
In JavaScript, objects inherit properties from a prototype, and almost all of them ultimately inherit from Object.prototype. Prototype pollution happens when an attacker can write to that shared prototype, usually through a key such as __proto__ or constructor.prototype in data the application merges or copies.
Once polluted, every object that does not set the property itself inherits the attacker's value. A single request can change defaults across the whole running application.
Why it matters
The effects depend on what the code reads from its objects. In a browser it can turn into script injection. On a Node.js server it can bypass checks, change configuration or reach code execution, if the polluted value ends up in a command or template.
Because the cause sits in a library or helper, not in your own feature code, it is easy to miss. A dependency update that fixes it is often the first you hear, which makes it a common dependency vulnerability finding.
How it shows up
It shows up in functions that merge, clone, extend or set a value by a path such as a.b.c, applied to JSON or query parameters from outside. Parsers for query strings and deep-merge helpers have been affected in the past.
The mistakes repeat. User-controlled keys are copied without filtering. Objects used as lookup tables are plain objects. Check libraries are patched, reject __proto__, constructor and prototype keys, use Map or Object.create(null) for dictionaries, and validate input against a schema.
Questions people ask
Prototype pollution, answered
What is the __proto__ property?
It is an accessor that exposes an object's prototype. Assigning through it, or through constructor.prototype, can reach the shared base object if code walks a user-supplied path.
Filtering those key names is a common defence, though not a complete one by itself.
Is prototype pollution only a Node.js problem?
No. It appears in browser code too, where it can feed into cross-site scripting. On the server it can alter behaviour for every request until the process restarts.
The cause is the same on both sides.
Does freezing Object.prototype fix it?
It blocks the write, so pollution fails, but it can break libraries that expect to modify built-ins. It works as a stop-gap and needs testing.
Fixing the unsafe merge and validating input remains the real cure.
How do we find it?
Review any code that merges or sets properties from outside data, and test with payloads containing __proto__ and constructor keys. Then see whether behaviour changes on later requests.
Static checks and testing the running app complement each other.
Is it the same as injection?
It is related. Untrusted data changes how the program behaves, but the payload targets the object model, not a query or command. It can still end in remote code execution.
The usual rule applies: treat outside data as untrusted.
Related
Terms that sit next to this one
Injection
Input that ends up running as a command instead of being read as text.
Dependency vulnerability
A known flaw in a library your application ships.
Mass assignment
When the fields in a request get written straight onto a record.
Untrusted input
Anything that arrived from outside your own code, and is therefore suspect.
Remote code execution
Getting a server to run commands of an attacker's choosing.
What does your merge function copy?
In white-box mode we read your code while testing the running app, so a finding can point to the file and line. Each one is something we exploited. Ask us to run it on one of your applications.
Or start with a $199 pilot on one application: thirty days, success criteria agreed before day one, credited against the annual if you convert.