From ed5684d209276fdfb7879a6ba5f944770cadbe38 Mon Sep 17 00:00:00 2001 From: Teddy Katz Date: Tue, 5 Feb 2019 20:44:08 -0500 Subject: [PATCH 1/2] Docs: clarify motivation for no-prototype-builtins The first section in the no-prototype-builtins docs mentions objects created with Object.create(null), but does not mention builtin shadowing (which is arguably a much more compelling reason to use the rule). This commit updates the description to clarify the risks of using prototype builtins on user input. --- docs/rules/no-prototype-builtins.md | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/docs/rules/no-prototype-builtins.md b/docs/rules/no-prototype-builtins.md index e2dd4f5b99f..6137f8bc5a5 100644 --- a/docs/rules/no-prototype-builtins.md +++ b/docs/rules/no-prototype-builtins.md @@ -2,6 +2,10 @@ In ECMAScript 5.1, `Object.create` was added, which enables the creation of objects with a specified `[[Prototype]]`. `Object.create(null)` is a common pattern used to create objects that will be used as a Map. This can lead to errors when it is assumed that objects will have properties from `Object.prototype`. This rule prevents calling some `Object.prototype` methods directly from an object. +Additionally, objects can have properties that shadow the builtins on `Object.prototype`, potentially causing unintended behavior or denial-of-service security vulnerabilities. For example, it would be unsafe for a webserver to parse JSON input from a client and call `hasOwnProperty` directly on the resulting object, because a malicious client could send a JSON value like `{"hasOwnProperty": 1}` and cause the server to crash. + +To avoid subtle bugs like this, it's better to always call these methods from `Object.prototype`. For example, `foo.hasOwnProperty("bar")` should be replaced with `Object.prototype.hasOwnProperty.call(foo, "bar")`. + ## Rule Details This rule disallows calling some `Object.prototype` methods directly on object instances. @@ -32,4 +36,4 @@ var barIsEnumerable = {}.propertyIsEnumerable.call(foo, "bar"); ## When Not To Use It -You may want to turn this rule off if you will never use an object that shadows an `Object.prototype` method or which does not inherit from `Object.prototype`. +You may want to turn this rule off if your code never handles user input, and you will never use an object that shadows an `Object.prototype` method or which does not inherit from `Object.prototype`. From 658d6a6d85a9b2352ea2a72e46e3b70d747f055b Mon Sep 17 00:00:00 2001 From: Teddy Katz Date: Tue, 5 Feb 2019 22:49:13 -0500 Subject: [PATCH 2/2] Update "When not to use it" wording --- docs/rules/no-prototype-builtins.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/rules/no-prototype-builtins.md b/docs/rules/no-prototype-builtins.md index 6137f8bc5a5..7132bcbdfd4 100644 --- a/docs/rules/no-prototype-builtins.md +++ b/docs/rules/no-prototype-builtins.md @@ -36,4 +36,4 @@ var barIsEnumerable = {}.propertyIsEnumerable.call(foo, "bar"); ## When Not To Use It -You may want to turn this rule off if your code never handles user input, and you will never use an object that shadows an `Object.prototype` method or which does not inherit from `Object.prototype`. +You may want to turn this rule off if your code only touches objects with hardcoded keys, and you will never use an object that shadows an `Object.prototype` method or which does not inherit from `Object.prototype`.