Skip to content

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

critical-js.md #1359

Closed
bgoonz opened this issue Dec 25, 2021 · 0 comments
Closed

critical-js.md #1359

bgoonz opened this issue Dec 25, 2021 · 0 comments
Labels
enhancement New feature or request security fix Security fix generated by WhiteSource security vulnerability Security vulnerability detected by WhiteSource

Comments

@bgoonz
Copy link
Owner

bgoonz commented Dec 25, 2021

notes/past-itterations/scrap/js/prism.js

Critical icon CRITICALError Prone

Do not access Object.prototype method 'hasOwnProperty' from target object.

View File

Reported by ESLint Time to fix: 5 minutes 

60

                    var r = (t = t || C.languages)[n],

61

                        i = {};

62

                    for (var l in r)

63

                        if (r.hasOwnProperty(l)) {

64

                            if (l == e) for (var o in a) a.hasOwnProperty(o) && (i[o] = a[o]);

65

                            a.hasOwnProperty(l) || (i[l] = r[l]);
Why is this an issue?

Disallow use of Object.prototypes builtins directly (no-prototype-builtins)

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.

Examples of incorrect code for this rule:

/*eslint no-prototype-builtins: "error"*/

var hasBarProperty = foo.hasOwnProperty("bar");

var isPrototypeOfBar = foo.isPrototypeOf(bar);

var barIsEnumerable = foo.propertyIsEnumerable("bar");

Examples of correct code for this rule:

/*eslint no-prototype-builtins: "error"*/

var hasBarProperty = Object.prototype.hasOwnProperty.call(foo, "bar");

var isPrototypeOfBar = Object.prototype.isPrototypeOf.call(foo, bar);

var barIsEnumerable = {}.propertyIsEnumerable.call(foo, "bar");

When Not To Use It

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.

Related code pattern

No prototype builtins

Javascript TypeScript

Critical icon CRITICALError Prone

Do not access Object.prototype method 'hasOwnProperty' from target object.

View File

Reported by ESLint Time to fix: 5 minutes 

77

                    r = r || {};

78

                    var i = C.util.objId;

79

                    for (var l in a)

80

                        if (a.hasOwnProperty(l)) {

81

                            n.call(a, l, a[l], t || l);

82

                            var o = a[l],
Why is this an issue?

Disallow use of Object.prototypes builtins directly (no-prototype-builtins)

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.

Examples of incorrect code for this rule:

/*eslint no-prototype-builtins: "error"*/

var hasBarProperty = foo.hasOwnProperty("bar");

var isPrototypeOfBar = foo.isPrototypeOf(bar);

var barIsEnumerable = foo.propertyIsEnumerable("bar");

Examples of correct code for this rule:

/*eslint no-prototype-builtins: "error"*/

var hasBarProperty = Object.prototype.hasOwnProperty.call(foo, "bar");

var isPrototypeOfBar = Object.prototype.isPrototypeOf.call(foo, bar);

var barIsEnumerable = {}.propertyIsEnumerable.call(foo, "bar");

When Not To Use It

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.

Related code pattern

No prototype builtins

Javascript TypeScript

Critical icon CRITICALError Prone

Unexpected comma in middle of array.

View File

Reported by ESLint Time to fix: 5 minutes 

99

            },

100

            highlightElement: function (e, a, n) {

101

                for (var t, r = 'none', i = e; i && !c.test(i.className); ) i = i.parentNode;

102

                i && ((r = (i.className.match(c) || [, 'none'])[1].toLowerCase()), (t = C.languages[r])),

103

                    (e.className = e.className.replace(c, '').replace(/\s+/g, ' ') + ' language-' + r),

104

                    e.parentNode &&
Why is this an issue?

disallow sparse arrays (no-sparse-arrays)

Sparse arrays contain empty slots, most frequently due to multiple commas being used in an array literal, such as:

var items = [,,];

While the items array in this example has a length of 2, there are actually no values in items[0] or items[1]. The fact that the array literal is valid with only commas inside, coupled with the length being set and actual item values not being set, make sparse arrays confusing for many developers. Consider the following:

var colors = [ "red",, "blue" ];

In this example, the colors array has a length of 3. But did the developer intend for there to be an empty spot in the middle of the array? Or is it a typo?

The confusion around sparse arrays defined in this manner is enough that it's recommended to avoid using them unless you are certain that they are useful in your code.

Rule Details

This rule disallows sparse array literals which have "holes" where commas are not preceded by elements. It does not apply to a trailing comma following the last element.

Examples of incorrect code for this rule:

/*eslint no-sparse-arrays: "error"*/

var items = [,];
var colors = [ "red",, "blue" ];

Examples of correct code for this rule:

/*eslint no-sparse-arrays: "error"*/

var items = [];
var items = new Array(23);

// trailing comma (after the last element) is not a problem
var colors = [ "red", "blue", ];

When Not To Use It

If you want to use sparse arrays, then it is safe to disable this rule.

Further Reading

Related code pattern

No sparse arrays

Javascript TypeScript

Critical icon CRITICALError Prone

Do not access Object.prototype method 'hasOwnProperty' from target object.

View File

Reported by ESLint Time to fix: 5 minutes 

141

            },

142

            matchGrammar: function (e, a, n, t, r, i, l) {

143

                for (var o in n)

144

                    if (n.hasOwnProperty(o) && n[o]) {

145

                        if (o == l) return;

146

                        var s = n[o];
Why is this an issue?

Disallow use of Object.prototypes builtins directly (no-prototype-builtins)

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.

Examples of incorrect code for this rule:

/*eslint no-prototype-builtins: "error"*/

var hasBarProperty = foo.hasOwnProperty("bar");

var isPrototypeOfBar = foo.isPrototypeOf(bar);

var barIsEnumerable = foo.propertyIsEnumerable("bar");

Examples of correct code for this rule:

/*eslint no-prototype-builtins: "error"*/

var hasBarProperty = Object.prototype.hasOwnProperty.call(foo, "bar");

var isPrototypeOfBar = Object.prototype.isPrototypeOf.call(foo, bar);

var barIsEnumerable = {}.propertyIsEnumerable.call(foo, "bar");

When Not To Use It

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.

Related code pattern

No prototype builtins

Javascript TypeScript

Critical icon CRITICALError Prone

Empty block statement.

View File

Reported by ESLint Time to fix: 5 minutes 

543

                o = e.getAttribute('data-label');

544

            try {

545

                a = document.querySelector('template#' + o);

546

            } catch (t) {}

547

            return (

548

                a
Why is this an issue?

disallow empty block statements (no-empty)

Empty block statements, while not technically errors, usually occur due to refactoring that wasn't completed. They can cause confusion when reading code.

Rule Details

This rule disallows empty block statements. This rule ignores block statements which contain a comment (for example, in an empty catch or finally block of a try statement to indicate that execution should continue regardless of errors).

Examples of incorrect code for this rule:

/*eslint no-empty: "error"*/

if (foo) {
}

while (foo) {
}

switch(foo) {
}

try {
    doSomething();
} catch(ex) {

} finally {

}

Examples of correct code for this rule:

/*eslint no-empty: "error"*/

if (foo) {
    // empty
}

while (foo) {
    /* empty */
}

try {
    doSomething();
} catch (ex) {
    // continue regardless of error
}

try {
    doSomething();
} finally {
    /* continue regardless of error */
}

Options

This rule has an object option for exceptions:

  • "allowEmptyCatch": true allows empty catch clauses (that is, which do not contain a comment)

allowEmptyCatch

Examples of additional correct code for this rule with the { "allowEmptyCatch": true } option:

/* eslint no-empty: ["error", { "allowEmptyCatch": true }] */
try {
    doSomething();
} catch (ex) {}

try {
    doSomething();
}
catch (ex) {}
finally {
    /* continue regardless of error */
}

When Not To Use It

If you intentionally use empty block statements then you can disable this rule.

Related Rules

Related code pattern

No empty

Javascript TypeScript

Critical icon CRITICALError Prone

Unexpected comma in middle of array.

View File

Reported by ESLint Time to fix: 5 minutes 

649

                },

650

                getLanguage: function (e) {

651

                    for (; e && !c.test(e.className); ) e = e.parentElement;

652

                    return e ? (e.className.match(c) || [, 'none'])[1].toLowerCase() : 'none';

653

                },

654

                currentScript: function () {
Why is this an issue?

disallow sparse arrays (no-sparse-arrays)

Sparse arrays contain empty slots, most frequently due to multiple commas being used in an array literal, such as:

var items = [,,];

While the items array in this example has a length of 2, there are actually no values in items[0] or items[1]. The fact that the array literal is valid with only commas inside, coupled with the length being set and actual item values not being set, make sparse arrays confusing for many developers. Consider the following:

var colors = [ "red",, "blue" ];

In this example, the colors array has a length of 3. But did the developer intend for there to be an empty spot in the middle of the array? Or is it a typo?

The confusion around sparse arrays defined in this manner is enough that it's recommended to avoid using them unless you are certain that they are useful in your code.

Rule Details

This rule disallows sparse array literals which have "holes" where commas are not preceded by elements. It does not apply to a trailing comma following the last element.

Examples of incorrect code for this rule:

/*eslint no-sparse-arrays: "error"*/

var items = [,];
var colors = [ "red",, "blue" ];

Examples of correct code for this rule:

/*eslint no-sparse-arrays: "error"*/

var items = [];
var items = new Array(23);

// trailing comma (after the last element) is not a problem
var colors = [ "red", "blue", ];

When Not To Use It

If you want to use sparse arrays, then it is safe to disable this rule.

Further Reading

Related code pattern

No sparse arrays

Javascript TypeScript

Critical icon CRITICALError Prone

Do not access Object.prototype method 'hasOwnProperty' from target object.

View File

Reported by ESLint Time to fix: 5 minutes 

690

                        i = {};

691

                    for (var l in a)

692

                        if (a.hasOwnProperty(l)) {

693

                            if (l == e) for (var o in n) n.hasOwnProperty(o) && (i[o] = n[o]);

694

                            n.hasOwnProperty(l) || (i[l] = a[l]);

695

                        }
Why is this an issue?

Disallow use of Object.prototypes builtins directly (no-prototype-builtins)

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.

Examples of incorrect code for this rule:

/*eslint no-prototype-builtins: "error"*/

var hasBarProperty = foo.hasOwnProperty("bar");

var isPrototypeOfBar = foo.isPrototypeOf(bar);

var barIsEnumerable = foo.propertyIsEnumerable("bar");

Examples of correct code for this rule:

/*eslint no-prototype-builtins: "error"*/

var hasBarProperty = Object.prototype.hasOwnProperty.call(foo, "bar");

var isPrototypeOfBar = Object.prototype.isPrototypeOf.call(foo, bar);

var barIsEnumerable = {}.propertyIsEnumerable.call(foo, "bar");

When Not To Use It

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.

Related code pattern

No prototype builtins

Javascript TypeScript

Critical icon CRITICALError Prone

Do not access Object.prototype method 'hasOwnProperty' from target object.

View File

Reported by ESLint Time to fix: 5 minutes 

706

                    a = a || {};

707

                    var i = M.util.objId;

708

                    for (var l in n)

709

                        if (n.hasOwnProperty(l)) {

710

                            t.call(n, l, n[l], r || l);

711

                            var o = n[l],
Why is this an issue?

Disallow use of Object.prototypes builtins directly (no-prototype-builtins)

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.

Examples of incorrect code for this rule:

/*eslint no-prototype-builtins: "error"*/

var hasBarProperty = foo.hasOwnProperty("bar");

var isPrototypeOfBar = foo.isPrototypeOf(bar);

var barIsEnumerable = foo.propertyIsEnumerable("bar");

Examples of correct code for this rule:

/*eslint no-prototype-builtins: "error"*/

var hasBarProperty = Object.prototype.hasOwnProperty.call(foo, "bar");

var isPrototypeOfBar = Object.prototype.isPrototypeOf.call(foo, bar);

var barIsEnumerable = {}.propertyIsEnumerable.call(foo, "bar");

When Not To Use It

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.

Related code pattern

No prototype builtins

Javascript TypeScript

static/js/google-search.js

Critical icon CRITICALError Prone

Expected a conditional expression and instead saw an assignment.

Bryan C Guner 15 days ago

View File

Reported by ESLint Time to fix: 5 minutes 

17

      createScriptURL: l

18

    })

19

  } catch (e) { g.console && g.console.error(e.message) } t = b

20

} a = (b = t) ? b.createScriptURL(a) : a; return new z(a, y)

21

}, I = function (a, b, d) { if (null == d) return b; if ("string" === typeof d) return d ? a + encodeURIComponent(d) : ""; for (var e in d) if (Object.prototype.hasOwnProperty.call(d, e)) { var c = d[e]; c = Array.isArray(c) ? c : [c]; for (var f = 0; f < c.length; f++) { var h = c[f]; null != h && (b || (b = a), b += (b.length > a.length ? "&" : "") + encodeURIComponent(e) + "=" + encodeURIComponent(String(h))) } } return b }; var aa = /^[\w+/_-]+[=]{0,2}$/; var ba = new w(u, "https://www.google.com/cse/static/style/look/%{versionDir}%{versionSlash}%{theme}.css"), K = new w(u, "https://www.google.com/cse/static/element/%{versionDir}%{versionSlash}default%{experiment}+%{lang}.css"), H = new w(u, "https://www.google.com/cse/static/element/%{versionDir}%{versionSlash}cse_element__%{lang}.js"), L = new w(u, "/"); window.__gcse = window.__gcse || {}; window.__gcse.ct = Date.now();

22

window.__gcse.scb = function () { var a = window.gcse; M() || delete opts.rawCss; var b = ca(a.initializationCallback || a.callback); google.search.cse.element.init(opts) && ("explicit" !== a.parsetags ? "complete" === document.readyState || "interactive" === document.readyState ? (google.search.cse.element.go(), b && b()) : google.setOnLoadCallback(function () { google.search.cse.element.go(); b && b() }, !0) : b && b()) }; function ca(a) { return "function" === typeof a ? a : "string" === typeof a && "function" === typeof window[a] ? window[a] : null }

Why is this an issue?

disallow assignment operators in conditional statements (no-cond-assign)

In conditional statements, it is very easy to mistype a comparison operator (such as ==) as an assignment operator (such as =). For example:

// Check the user's job title
if (user.jobTitle = "manager") {
    // user.jobTitle is now incorrect
}

There are valid reasons to use assignment operators in conditional statements. However, it can be difficult to tell whether a specific assignment was intentional.

Rule Details

This rule disallows ambiguous assignment operators in test conditions of if, for, while, and do...while statements.

Options

This rule has a string option:

  • "except-parens" (default) allows assignments in test conditions only if they are enclosed in parentheses (for example, to allow reassigning a variable in the test of a while or do...while loop)
  • "always" disallows all assignments in test conditions

except-parens

Examples of incorrect code for this rule with the default "except-parens" option:

/*eslint no-cond-assign: "error"*/

// Unintentional assignment
var x;
if (x = 0) {
    var b = 1;
}

// Practical example that is similar to an error
function setHeight(someNode) {
    "use strict";
    do {
        someNode.height = "100px";
    } while (someNode = someNode.parentNode);
}

Examples of correct code for this rule with the default "except-parens" option:

/*eslint no-cond-assign: "error"*/

// Assignment replaced by comparison
var x;
if (x === 0) {
    var b = 1;
}

// Practical example that wraps the assignment in parentheses
function setHeight(someNode) {
    "use strict";
    do {
        someNode.height = "100px";
    } while ((someNode = someNode.parentNode));
}

// Practical example that wraps the assignment and tests for 'null'
function setHeight(someNode) {
    "use strict";
    do {
        someNode.height = "100px";
    } while ((someNode = someNode.parentNode) !== null);
}

always

Examples of incorrect code for this rule with the "always" option:

/*eslint no-cond-assign: ["error", "always"]*/

// Unintentional assignment
var x;
if (x = 0) {
    var b = 1;
}

// Practical example that is similar to an error
function setHeight(someNode) {
    "use strict";
    do {
        someNode.height = "100px";
    } while (someNode = someNode.parentNode);
}

// Practical example that wraps the assignment in parentheses
function setHeight(someNode) {
    "use strict";
    do {
        someNode.height = "100px";
    } while ((someNode = someNode.parentNode));
}

// Practical example that wraps the assignment and tests for 'null'
function setHeight(someNode) {
    "use strict";
    do {
        someNode.height = "100px";
    } while ((someNode = someNode.parentNode) !== null);
}

Examples of correct code for this rule with the "always" option:

/*eslint no-cond-assign: ["error", "always"]*/

// Assignment replaced by comparison
var x;
if (x === 0) {
    var b = 1;
}

Related Rules

Related code pattern

No cond assign

Javascript TypeScript

Critical icon CRITICALError Prone

Unnecessary semicolon.

30

}; var O, G = opts_.usqp ? { usqp: opts_.usqp } : {}, P = opts_.language.toLowerCase(); O = opts_.cselibVersion ? J({ versionDir: opts_.cselibVersion, versionSlash: L, lang: P }) : J({ versionDir: "", versionSlash: "", lang: P }); var Q = window.__gcse.scb, R = document.createElement("script"); R.src = A(O); var S, T, U = (R.ownerDocument && R.ownerDocument.defaultView || window).document, V = null === (T = U.querySelector) || void 0 === T ? void 0 : T.call(U, "script[nonce]"); (S = V ? V.nonce || V.getAt

static/js/plugins.js

Critical icon CRITICALError Prone

Do not access Object.prototype method 'hasOwnProperty' from target object.

Bryan C Guner 5 months ago

View File

Reported by ESLint Time to fix: 5 minutes 

115

            return (

116

                Array.prototype.forEach.call(arguments, function (e) {

117

                    for (var t in e) {

118

                        if (!e.hasOwnProperty(t)) return;

119

                        n[t] = e[t];

120

                    }
Why is this an issue?

Disallow use of Object.prototypes builtins directly (no-prototype-builtins)

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.

Examples of incorrect code for this rule:

/*eslint no-prototype-builtins: "error"*/

var hasBarProperty = foo.hasOwnProperty("bar");

var isPrototypeOfBar = foo.isPrototypeOf(bar);

var barIsEnumerable = foo.propertyIsEnumerable("bar");

Examples of correct code for this rule:

/*eslint no-prototype-builtins: "error"*/

var hasBarProperty = Object.prototype.hasOwnProperty.call(foo, "bar");

var isPrototypeOfBar = Object.prototype.isPrototypeOf.call(foo, bar);

var barIsEnumerable = {}.propertyIsEnumerable.call(foo, "bar");

When Not To Use It

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.

Related code pattern

No prototype builtins

Javascript TypeScript

Critical icon CRITICALError Prone

Do not access Object.prototype method 'hasOwnProperty' from target object.

Bryan C Guner 5 months ago

View File

Reported by ESLint Time to fix: 5 minutes 

499

                return (

500

                    Array.prototype.forEach.call(arguments, function (e) {

501

                        for (var n in e) {

502

                            if (!e.hasOwnProperty(n)) return;

503

                            t[n] = e[n];

504

                        }
Why is this an issue?

Disallow use of Object.prototypes builtins directly (no-prototype-builtins)

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.

Examples of incorrect code for this rule:

/*eslint no-prototype-builtins: "error"*/

var hasBarProperty = foo.hasOwnProperty("bar");

var isPrototypeOfBar = foo.isPrototypeOf(bar);

var barIsEnumerable = foo.propertyIsEnumerable("bar");

Examples of correct code for this rule:

/*eslint no-prototype-builtins: "error"*/

var hasBarProperty = Object.prototype.hasOwnProperty.call(foo, "bar");

var isPrototypeOfBar = Object.prototype.isPrototypeOf.call(foo, bar);

var barIsEnumerable = {}.propertyIsEnumerable.call(foo, "bar");

When Not To Use It

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.

Related code pattern

No prototype builtins

Javascript TypeScript

static/js/prism.js

Critical icon CRITICALError Prone

Do not access Object.prototype method 'hasOwnProperty' from target object.

Bryan C Guner 5 months ago

View File

Reported by ESLint Time to fix: 5 minutes 

31

                    switch (((t = t || {}), i)) {

32

                        case 'Object':

33

                            if (((a = C.util.objId(e)), t[a])) return t[a];

34

                            for (var l in ((r = {}), (t[a] = r), e)) e.hasOwnProperty(l) && (r[l] = n(e[l], t));

35

                            return r;

36

                        case 'Array':
Why is this an issue?

Disallow use of Object.prototypes builtins directly (no-prototype-builtins)

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.

Examples of incorrect code for this rule:

/*eslint no-prototype-builtins: "error"*/

var hasBarProperty = foo.hasOwnProperty("bar");

var isPrototypeOfBar = foo.isPrototypeOf(bar);

var barIsEnumerable = foo.propertyIsEnumerable("bar");

Examples of correct code for this rule:

/*eslint no-prototype-builtins: "error"*/

var hasBarProperty = Object.prototype.hasOwnProperty.call(foo, "bar");

var isPrototypeOfBar = Object.prototype.isPrototypeOf.call(foo, bar);

var barIsEnumerable = {}.propertyIsEnumerable.call(foo, "bar");

When Not To Use It

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.

Related code pattern

No prototype builtins

Javascript TypeScript

Critical icon CRITICALError Prone

Do not access Object.prototype method 'hasOwnProperty' from target object.

Bryan C Guner 5 months ago

View File

Reported by ESLint Time to fix: 5 minutes 

61

                        i = {};

62

                    for (var l in r)

63

                        if (r.hasOwnProperty(l)) {

64

                            if (l == e) for (var o in a) a.hasOwnProperty(o) && (i[o] = a[o]);

65

                            a.hasOwnProperty(l) || (i[l] = r[l]);

66

                        }
Why is this an issue?

Disallow use of Object.prototypes builtins directly (no-prototype-builtins)

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.

Examples of incorrect code for this rule:

/*eslint no-prototype-builtins: "error"*/

var hasBarProperty = foo.hasOwnProperty("bar");

var isPrototypeOfBar = foo.isPrototypeOf(bar);

var barIsEnumerable = foo.propertyIsEnumerable("bar");

Examples of correct code for this rule:

/*eslint no-prototype-builtins: "error"*/

var hasBarProperty = Object.prototype.hasOwnProperty.call(foo, "bar");

var isPrototypeOfBar = Object.prototype.isPrototypeOf.call(foo, bar);

var barIsEnumerable = {}.propertyIsEnumerable.call(foo, "bar");

When Not To Use It

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.

Related code pattern

No prototype builtins

Javascript TypeScript

Critical icon CRITICALError Prone

Do not access Object.prototype method 'hasOwnProperty' from target object.

Bryan C Guner 5 months ago

View File

Reported by ESLint Time to fix: 5 minutes 

62

                    for (var l in r)

63

                        if (r.hasOwnProperty(l)) {

64

                            if (l == e) for (var o in a) a.hasOwnProperty(o) && (i[o] = a[o]);

65

                            a.hasOwnProperty(l) || (i[l] = r[l]);

66

                        }

67

                    var s = t[n];
Why is this an issue?

Disallow use of Object.prototypes builtins directly (no-prototype-builtins)

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.

Examples of incorrect code for this rule:

/*eslint no-prototype-builtins: "error"*/

var hasBarProperty = foo.hasOwnProperty("bar");

var isPrototypeOfBar = foo.isPrototypeOf(bar);

var barIsEnumerable = foo.propertyIsEnumerable("bar");

Examples of correct code for this rule:

/*eslint no-prototype-builtins: "error"*/

var hasBarProperty = Object.prototype.hasOwnProperty.call(foo, "bar");

var isPrototypeOfBar = Object.prototype.isPrototypeOf.call(foo, bar);

var barIsEnumerable = {}.propertyIsEnumerable.call(foo, "bar");

When Not To Use It

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.

Related code pattern

No prototype builtins

Javascript TypeScript

Critical icon CRITICALError Prone

Do not access Object.prototype method 'hasOwnProperty' from target object.

Bryan C Guner 5 months ago

View File

Reported by ESLint Time to fix: 5 minutes 

77

                    r = r || {};

78

                    var i = C.util.objId;

79

                    for (var l in a)

80

                        if (a.hasOwnProperty(l)) {

81

                            n.call(a, l, a[l], t || l);

82

                            var o = a[l],
Why is this an issue?

Disallow use of Object.prototypes builtins directly (no-prototype-builtins)

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.

Examples of incorrect code for this rule:

/*eslint no-prototype-builtins: "error"*/

var hasBarProperty = foo.hasOwnProperty("bar");

var isPrototypeOfBar = foo.isPrototypeOf(bar);

var barIsEnumerable = foo.propertyIsEnumerable("bar");

Examples of correct code for this rule:

/*eslint no-prototype-builtins: "error"*/

var hasBarProperty = Object.prototype.hasOwnProperty.call(foo, "bar");

var isPrototypeOfBar = Object.prototype.isPrototypeOf.call(foo, bar);

var barIsEnumerable = {}.propertyIsEnumerable.call(foo, "bar");

When Not To Use It

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.

Related code pattern

No prototype builtins

Javascript TypeScript

Critical icon CRITICALError Prone

Do not access Object.prototype method 'hasOwnProperty' from target object.

Bryan C Guner 5 months ago

View File

Reported by ESLint Time to fix: 5 minutes 

141

            },

142

            matchGrammar: function (e, a, n, t, r, i, l) {

143

                for (var o in n)

144

                    if (n.hasOwnProperty(o) && n[o]) {

145

                        if (o == l) return;

146

                        var s = n[o];
Why is this an issue?

Disallow use of Object.prototypes builtins directly (no-prototype-builtins)

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.

Examples of incorrect code for this rule:

/*eslint no-prototype-builtins: "error"*/

var hasBarProperty = foo.hasOwnProperty("bar");

var isPrototypeOfBar = foo.isPrototypeOf(bar);

var barIsEnumerable = foo.propertyIsEnumerable("bar");

Examples of correct code for this rule:

/*eslint no-prototype-builtins: "error"*/

var hasBarProperty = Object.prototype.hasOwnProperty.call(foo, "bar");

var isPrototypeOfBar = Object.prototype.isPrototypeOf.call(foo, bar);

var barIsEnumerable = {}.propertyIsEnumerable.call(foo, "bar");

When Not To Use It

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.

Related code pattern

No prototype builtins

Javascript TypeScript

Critical icon CRITICALError Prone

Do not access Object.prototype method 'hasOwnProperty' from target object.

Bryan C Guner 5 months ago

View File

Reported by ESLint Time to fix: 5 minutes 

629

                    switch (((r = r || {}), M.util.type(e))) {

630

                        case 'Object':

631

                            if (((n = M.util.objId(e)), r[n])) return r[n];

632

                            for (var i in ((a = {}), (r[n] = a), e)) e.hasOwnProperty(i) && (a[i] = t(e[i], r));

633

                            return a;

634

                        case 'Array':
Why is this an issue?

Disallow use of Object.prototypes builtins directly (no-prototype-builtins)

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.

Examples of incorrect code for this rule:

/*eslint no-prototype-builtins: "error"*/

var hasBarProperty = foo.hasOwnProperty("bar");

var isPrototypeOfBar = foo.isPrototypeOf(bar);

var barIsEnumerable = foo.propertyIsEnumerable("bar");

Examples of correct code for this rule:

/*eslint no-prototype-builtins: "error"*/

var hasBarProperty = Object.prototype.hasOwnProperty.call(foo, "bar");

var isPrototypeOfBar = Object.prototype.isPrototypeOf.call(foo, bar);

var barIsEnumerable = {}.propertyIsEnumerable.call(foo, "bar");

When Not To Use It

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.

Related code pattern

No prototype builtins

Javascript TypeScript

Critical icon CRITICALError Prone

Do not access Object.prototype method 'hasOwnProperty' from target object.

Bryan C Guner 5 months ago

View File

Reported by ESLint Time to fix: 5 minutes 

690

                        i = {};

691

                    for (var l in a)

692

                        if (a.hasOwnProperty(l)) {

693

                            if (l == e) for (var o in n) n.hasOwnProperty(o) && (i[o] = n[o]);

694

                            n.hasOwnProperty(l) || (i[l] = a[l]);

695

                        }
Why is this an issue?

Disallow use of Object.prototypes builtins directly (no-prototype-builtins)

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.

Examples of incorrect code for this rule:

/*eslint no-prototype-builtins: "error"*/

var hasBarProperty = foo.hasOwnProperty("bar");

var isPrototypeOfBar = foo.isPrototypeOf(bar);

var barIsEnumerable = foo.propertyIsEnumerable("bar");

Examples of correct code for this rule:

/*eslint no-prototype-builtins: "error"*/

var hasBarProperty = Object.prototype.hasOwnProperty.call(foo, "bar");

var isPrototypeOfBar = Object.prototype.isPrototypeOf.call(foo, bar);

var barIsEnumerable = {}.propertyIsEnumerable.call(foo, "bar");

When Not To Use It

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.

Related code pattern

No prototype builtins

Javascript TypeScript

Critical icon CRITICALError Prone

Do not access Object.prototype method 'hasOwnProperty' from target object.

Bryan C Guner 5 months ago

View File

Reported by ESLint Time to fix: 5 minutes 

706

                    a = a || {};

707

                    var i = M.util.objId;

708

                    for (var l in n)

709

                        if (n.hasOwnProperty(l)) {

710

                            t.call(n, l, n[l], r || l);

711

                            var o = n[l],
Why is this an issue?

Disallow use of Object.prototypes builtins directly (no-prototype-builtins)

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.

Examples of incorrect code for this rule:

/*eslint no-prototype-builtins: "error"*/

var hasBarProperty = foo.hasOwnProperty("bar");

var isPrototypeOfBar = foo.isPrototypeOf(bar);

var barIsEnumerable = foo.propertyIsEnumerable("bar");

Examples of correct code for this rule:

/*eslint no-prototype-builtins: "error"*/

var hasBarProperty = Object.prototype.hasOwnProperty.call(foo, "bar");

var isPrototypeOfBar = Object.prototype.isPrototypeOf.call(foo, bar);

var barIsEnumerable = {}.propertyIsEnumerable.call(foo, "bar");

When Not To Use It

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.

Related code pattern

No prototype builtins
@bgoonz bgoonz added enhancement New feature or request security fix Security fix generated by WhiteSource security vulnerability Security vulnerability detected by WhiteSource labels Dec 29, 2021
Repository owner locked and limited conversation to collaborators May 4, 2022
@bgoonz bgoonz converted this issue into discussion #2068 May 4, 2022

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

Assignees
No one assigned
Labels
enhancement New feature or request security fix Security fix generated by WhiteSource security vulnerability Security vulnerability detected by WhiteSource
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@bgoonz