AI-Generated Prototype Pollution Review Rules

Purpose

Use these rules when an AI coding assistant writes or edits JavaScript or TypeScript code that recursively merges, deep-clones, or assigns properties from an object built from untrusted input. The goal is to stop a generated config-merge, deep-clone, or "set a nested path from a string" helper from letting an attacker pollute Object.prototype (or another built-in prototype) and silently change behavior across the whole application.

This is a review policy, not a prototype-pollution tutorial. It tells reviewers what must be true about a generated change's object-merging code before the change is safe to merge.

Review Inputs

Collect enough context to know which objects are merged/cloned and where their keys come from.

• Every recursive merge, deep-clone, deep-assign, or dynamic nested-path-set helper the change adds or edits.
• Whether the source object being merged/cloned/read from can have its keys influenced by user input — a request body, query string, parsed JSON/YAML, an uploaded config file.
• Whether the change adds or updates a dependency that performs deep merging or cloning on external input, and what version is pinned.
• Whether plain object literals ({}) or Map/Set are used to hold untrusted key-value data.

Merge/Clone Guard Rules

• Any recursive merge, deep-clone, or deep-assign helper that processes untrusted input must explicitly reject or skip __proto__, constructor, and prototype as keys at every recursion level, not just the top level of the object.
• Do not assume a hand-rolled merge helper is safe because it "looks like" a well-known library's merge function; verify the guard is actually present in the diff.
• When adding or bumping a dependency that performs deep merging, cloning, or path-based assignment on external input (a config-merge library, a deep-set-by-string-path utility), check the version against known prototype-pollution advisories for that specific library rather than assuming popularity implies safety.
• Prefer a well-maintained, current-version library with a documented fix for this class of bug over a new hand-rolled merge implementation, when one is genuinely needed.

Safer Object Construction Rules

• Prefer Map/Set over a plain object literal for any collection built from untrusted keys — they have no prototype chain for attacker-supplied keys to pollute, unlike {}.
• When a plain object is required, construct it with Object.create(null) so it has no inherited prototype, or use { __proto__: null } as a fallback when Object.create isn't available in that context.
• Consider Object.freeze()/Object.seal() on built-in prototypes as an additional defense-in-depth layer, understanding it can break libraries that legitimately extend built-ins, so apply and test it deliberately rather than blanket-applying it.
• In Node.js, the --disable-proto=delete flag removes the __proto__ accessor entirely as a defense-in-depth measure; note it does not stop pollution via constructor.prototype, so it complements rather than replaces the merge/clone guards above.

Merge Blockers

Block merge when any of these is true.

• A recursive merge/clone/deep-assign helper processes untrusted input without excluding __proto__, constructor, and prototype keys at every level.
• A new or updated deep-merge/clone/path-assignment dependency is added without checking its version against known prototype-pollution advisories.
• Untrusted key-value data is stored in a plain object literal where a Map/Set or Object.create(null) would avoid the prototype-chain risk entirely, with no documented reason for the plain object.
• A hand-rolled merge/clone helper duplicates functionality an existing, already-guarded shared helper provides.

Review Checklist

• {"task": "Merge/clone helpers identified", "description": "Every recursive merge, deep-clone, or deep-assign helper touching untrusted input is identified"}
• {"task": "Dangerous keys excluded", "description": "proto, constructor, and prototype keys are explicitly rejected at every recursion level"}
• {"task": "Safer collection type used", "description": "Untrusted key-value data uses Map/Set or Object.create(null) rather than a plain {} literal, where practical"}
• {"task": "Dependency versions checked", "description": "Any deep-merge/clone/path-assignment dependency is checked against known prototype-pollution advisories for its version"}
• {"task": "No parallel unguarded helper", "description": "The change doesn't add a new merge/clone helper next to an existing guarded shared one"}

AI Review Rules

AI assistants can write and review object-merging code, but they should show their evidence.

• Ask the assistant to list every recursive merge/clone/deep-assign helper in the change and whether its input can be influenced by a user.
• Require the assistant to point to the exact line(s) that guard against __proto__/constructor/prototype keys, not just assert the helper is "safe."
• Have the assistant check the version of any deep-merge/clone dependency against known CVEs/advisories for that library.
• Do not let the assistant claim a merge helper is safe because tests only used ordinary key names; require a test with a __proto__ or constructor.prototype payload.
• Re-run review after any change to shared merge/clone/config-loading helpers or their dependencies.

Troubleshooting

• A legitimate key named constructor or prototype needs to be stored: use a Map for that data instead of a plain object, so the key name has no special meaning.
• Object.freeze() on a built-in prototype breaks a library: that library legitimately extends the built-in; scope the freeze more narrowly or drop it, and rely on the merge/clone-level guards instead.
• Tests only cover normal merge behavior: add a test that attempts to merge in a {"__proto__": {"polluted": true}} or {"constructor": {"prototype": {"polluted": true}}} payload and asserts ({}).polluted remains undefined afterward.
• A third-party library is flagged for a known prototype-pollution CVE: upgrade to the patched version rather than adding a local workaround, so the fix isn't silently lost on the next unrelated dependency bump.

Duplicate And History Check

Before adding a new merge/clone/deep-assign helper, confirm the codebase does not already have a shared, guarded utility for this. A generated change that adds a new hand-rolled merge function next to an existing guarded shared helper should be treated as suspicious — check whether the existing mechanism was simply not reused before introducing a second, possibly unguarded one.

Reference

Sources

• OWASP Prototype Pollution Prevention Cheat Sheet
• CWE-1321: Improperly Controlled Modification of Object Prototype Attributes ('Prototype Pollution')
• PortSwigger Web Security Academy: Prototype pollution
• GitHub Security Advisory GHSA-jf85-cpcp-j695: Prototype Pollution in lodash (CVE-2019-10744)

• Source repositorygithub.com 2026-07-16T13:01:56+00:00
• Documentationcheatsheetseries.owasp.org
• Submitted by lourincedaging0-commits2026-07-15