JavaScript Prototypes

How JavaScript prototypes work

JavaScript prototypes are the mechanism behind property inheritance and method sharing. When an object does not have a property of its own, the engine follows its prototype link and continues up the chain until it finds a match or reaches the end. That lookup model is what makes prototypes fundamental to object behaviour in JavaScript.

This is not just a language detail, it shapes how objects are constructed, extended, and reused. A prototype can be a plain object shared by many instances, so changes to shared methods are visible across that inheritance chain unless the object design deliberately prevents it.

Prototype chain lookup and delegation

The prototype chain is a delegation path, not a copy of properties into each object. This means reading a value can succeed even when the property lives higher in the chain, and method calls can resolve to shared functions rather than duplicated per instance. It is one reason JavaScript can express both classical-style inheritance patterns and more flexible composition patterns.

Because lookup is dynamic, the shape of the chain matters at runtime. A property on the object itself always takes precedence over a prototype property with the same name, which makes shadowing a normal part of JavaScript object design.

Prototype-based inheritance patterns

Prototypes support common patterns such as constructor functions, Object.create(), and class syntax, even though class in JavaScript still works through prototypes under the hood. The syntax may differ, but the underlying object relationship is still prototype delegation.

This model lets developers place shared methods on one prototype instead of recreating them for every object instance. That reduces duplication and makes method updates easier to apply consistently, but it also means the prototype becomes a shared trust boundary for every object linked to it.

Why prototypes matter for object design

Good prototype design helps keep object behaviour predictable. Shared methods belong on prototypes, while per-instance state belongs on the object itself. Mixing the two can create confusing overrides, accidental state leakage, or hard-to-trace behaviour when an inherited property masks an own property.

Prototype choice also affects maintainability. A clean chain makes objects easier to reason about, while deep or mutated chains can make behaviour less obvious, especially when code depends on inherited methods that may be replaced later.

Risk and Threat Considerations

Prototype misuse can create security and reliability problems when untrusted input is merged into objects or when code assumes inherited properties are safe. In JavaScript, prototype pollution can alter behaviour across many objects by changing shared prototype state, which is why it is a well-known application security issue.

Failure mechanism: Attacker-controlled keys such as __proto__, constructor.prototype, or unsafe deep-merge paths can write to a shared prototype instead of to one object, changing property lookup for later code.

Impact: A polluted prototype can cause logic changes, privilege checks to behave incorrectly, or unexpected methods and flags to appear across objects, especially in Node.js and browser code that relies on ordinary object literals.

Practitioner Guidance

Common misunderstanding: Prototype inheritance is often treated as harmless internal plumbing, but it becomes a governance issue when application code accepts external data into plain objects without guarding the prototype chain. In practice, the safest designs make the object model explicit rather than assuming default object behaviour is benign.

What to watch for: Review code that performs deep merges, deserialisation, or dynamic key assignment into plain objects, and prefer object patterns that reduce prototype exposure when shared behaviour is not needed. Pay particular attention when inherited methods or properties influence authorisation, configuration, or request handling.

Related resources from NHI Mgmt Group

• When should teams prefer functional prototypes over static design mocks?
• How should security teams detect phishing emails that hide behaviour behind HTML and JavaScript?
• What breaks when static scanners do not execute delayed JavaScript in attachments?
• How should security teams respond when a trusted JavaScript package is compromised?