oxc-project/oxc · error · OxcDiagnostic

do not access Object.prototype method {method_name:?} from t

Error message

do not access Object.prototype method {method_name:?} from target object

What it means

Lint diagnostic from eslint/no-prototype-builtins: hasOwnProperty, isPrototypeOf, or propertyIsEnumerable was called directly on an object (obj.hasOwnProperty(k)). Objects without a prototype (Object.create(null)) or with shadowed methods throw or lie; calling from Object.prototype is always safe.

Source

Thrown at crates/oxc_linter/src/rules/eslint/no_prototype_builtins.rs:9

use oxc_ast::AstKind;
use oxc_diagnostics::OxcDiagnostic;
use oxc_macros::declare_oxc_lint;
use oxc_span::{GetSpan, Span};

use crate::{AstNode, context::LintContext, rule::Rule};

fn no_prototype_builtins_diagnostic(method_name: &str, span: Span) -> OxcDiagnostic {
    OxcDiagnostic::warn(format!(
        "do not access Object.prototype method {method_name:?} from target object"
    ))
    .with_help(format!(
        "to avoid prototype pollution, use `Object.prototype.{method_name}.call` instead"
    ))
    .with_label(span)
}

#[derive(Debug, Default, Clone)]
pub struct NoPrototypeBuiltins;

declare_oxc_lint!(
    /// ### What it does
    ///
    /// Disallow calling some `Object.prototype` methods directly on objects.
    ///
    /// ### Why is this bad?
    ///

View on GitHub (pinned to e1e7af627c)

Solutions

  1. Use Object.prototype.hasOwnProperty.call(obj, key) as the help suggests
  2. Prefer Object.hasOwn(obj, key) in modern runtimes
  3. Use a Map or Set instead of relying on prototype-based key checks
Defensive patterns

Strategy: validation

When it happens

Trigger: Thrown at crates/oxc_linter/src/rules/eslint/no_prototype_builtins.rs:9 when the library encounters an invalid state.

Common situations: See trigger scenarios.


AI-assisted analysis of oxc-project/oxc@e1e7af627c (2026-08-20). Data as JSON: /api/errors/bbc0255b531c6930. Report an issue: GitHub.