__proto__

How __proto__ Works in JavaScript

__proto__ is a legacy accessor that exposes an object's prototype chain, so reads and writes can change where property lookup falls through. That makes it part of JavaScript's inheritance machinery, not just another ordinary field name. In modern code, the important distinction is between ordinary data properties and inherited behaviour, because the prototype link can change how an object behaves at runtime.

This matters because objects in JavaScript are often used as flexible maps, configuration blobs, or deserialized input containers. When code treats user-controlled keys as if they were harmless data, __proto__ can cross the line from metadata into object behaviour.

Why __proto__ Can Become Dangerous

The security issue is not the accessor itself, but the effect of letting untrusted input influence object inheritance. If application code merges objects, copies properties recursively, or assumes all keys are plain data, prototype mutation can reach other objects that share the same prototype ancestry. That is the core condition behind prototype pollution.

In practice, the danger is broader than a single polluted object. A changed prototype can alter authorization checks, feature flags, default options, serialization output, or application logic that relies on property presence. The impact depends on where the polluted property is later read, which is why prototype pollution is often a control-flow and data-integrity problem as much as a language quirk.

For a deeper treatment of the attack pattern and safe object design choices, see the Prototype Pollution Guide.

Where Exposure Usually Comes From

Exposure typically arises when JavaScript code accepts nested JSON, query parameters, form fields, or other attacker-controlled structures and then copies them into application objects without filtering reserved keys. Deep merge utilities, recursive assignment logic, and home-grown deserialisation are common places where prototype-sensitive keys slip through.

Risk also increases when a codebase assumes that object literals are safe containers for untrusted data. In those cases, the difference between a property on the object and a property on the prototype chain is easy to miss during review, especially if the code relies on dynamic key access or loosely validated merges.

Modern hardening guidance usually favours patterns that avoid mutating shared prototypes, such as using null-prototype objects where appropriate and blocking dangerous keys at boundaries. The same defensive thinking applies in browsers and Node.js, because the exploitability comes from how the application handles object shape, not from one runtime alone.

Safer Handling and Detection Patterns

The practical response is to reduce opportunities for prototype mutation and to validate object-handling code paths that ingest external input. Developers should prefer explicit schemas, allowlists, and safe merge primitives, and they should scrutinise any library that performs deep property expansion or convenience merging on behalf of the application.

Detection is partly code review and partly runtime awareness. Security testing should look for unexpected inherited properties, object shape drift after merges, and any code path where a reserved key can influence defaults or branching behaviour. After a suspected exposure, teams should review not only the vulnerable input path but also the objects and modules that may have consumed polluted properties later in the request lifecycle.

Prototype pollution is often subtle because the triggering input may look like ordinary JSON, while the blast radius appears much later in unrelated logic. That is why careful boundary validation and disciplined object design are the most reliable long-term controls.

Related resources from NHI Mgmt Group

• How do security teams decide whether to use JSON or Proto encoding for OpenTelemetry traces?
• What is the difference between a harmless __proto__ property and real prototype pollution?