← Lessons

quiz vs the machine

Gold1450

Security

Prototype Pollution Defense

How merging untrusted objects can poison shared behavior and how to block it.

5 min read · core · beat Gold to climb

The Risk

In some dynamic languages objects share behavior through a prototype chain. If code recursively merges or assigns keys from untrusted input without filtering, an attacker can set a special key that targets the shared prototype. Every object then inherits the injected property. This is prototype pollution. Depending on the app it can cause denial of service, logic bypass, or escalate into code execution where polluted values feed sensitive operations.

The danger is that one tainted merge changes defaults across the whole program, not just one object.

The Defense

  • Reject dangerous keys such as the prototype accessor and constructor names during merge and assignment.
  • Use safe data structures like a plain map keyed by strings rather than generic objects for user controlled lookups.
  • Validate input against a schema so unexpected keys never reach a merge.
  • Freeze base prototypes and prefer libraries that are hardened against this class.

Key idea

Filter or reject prototype targeting keys before merging untrusted data, and validate against a schema so no input can rewrite shared object behavior.

Check yourself

Answer to earn rating on the learn ladder.

1. What does prototype pollution change?

2. Which defense directly blocks the attack?

3. Why use a schema for input?