Prototype pollution is nasty. You can get into a state where your Node.js server is "poisoned" and all subsequent requests are owned by the attacker, depending on which object is polluted.
"Prototype pollution is a vulnerability that is specific to programming languages with prototype-based inheritance (the most common one being JavaScript)."<p>Naming is a difficult but critical aspect of conceptualizing a solution [1]. Programming, even when ad-hoc, relies on an internal conceptual model to guide the programmer. It pays to be pedantic with language.<p>A "prototype" per common understanding and dictionary definition strongly implies the act of "copying". Per that sense, the "prototype" of an Object is distinct object with its own distinct life-cycle and state space trajectory.<p>So it should be clarified here that the OP exploit is not an inherent weakness of prototype based OO approach, in principle. The Javascript "prototype" is really a "parent delegate". It is a <i>Delegated-Parent Inheritance</i> language, and the OP exploit <i>is</i> a feature/bug of delegate based composition approaches, by definition.<p>This inability by otherwise (obviously) intelligent people in naming things is an unfortunate pattern in computer science and software development. A historic favorite is "dynamic programming".<p>[1]: <a href="https://martinfowler.com/bliki/TwoHardThings.html" rel="nofollow">https://martinfowler.com/bliki/TwoHardThings.html</a>
one thing to note:<p><pre><code> for (key in obj) // do
</code></pre>
It’s better to use the first method below (when initializing):<p><pre><code> obj = Object.create(null)
obj = {}
</code></pre>
So you don’t inherit random keys from the chain, unless you intend to. Or use:<p><pre><code> Object.keys(obj).forEach(k
</code></pre>
Which doesn’t have this issue like the for-in loop version does.