ESLint + security 插件需手动配置才能检测安全漏洞，否则默认不报任何问题；必须安装插件、在配置文件中启用规则集、并在VSCode中正确启用ESLint，三者缺一不可。

ESLint + security 插件是目前最可控、最可调的 JS 安全检查方案，但装完不配规则、不启插件、不写注释，它根本不会报任何漏洞。

为什么 ESLint 默认不报安全问题

ESLint 本身只带基础语法和风格规则，默认不启用任何安全类规则。即使你装了 @eslint-community/eslint-plugin-security，它也不会自动激活——必须显式在 .eslintrc.cjs 或 .eslintrc.js 中引入并开启。

• 常见误判：看到插件已安装，就以为“JS 安全扫描已就绪”，结果提交了 eval(input) 都没提示
• 新版插件（如 v4.0+）默认关闭 javascript.security 规则集，更新后反而更安静
• eslint.enable 设为 true 只是启动引擎，不等于加载了安全规则

必须手动配置的三个关键点

缺一不可，否则所有安全规则形同虚设：

• 在项目根目录运行 npm install -D @eslint-community/eslint-plugin-security（注意不是全局安装）
• 修改 .eslintrc.cjs，确保包含：
  

  module.exports = {
    extends: ["plugin:@eslint-community/security/recommended"],
    plugins: ["@eslint-community/security"]
  };

• 确认 VSCode 设置中启用了 ESLint："eslint.enable": true，且禁用内置 JS 校验："javascript.validate.enable": false

哪些漏洞能被真正捕获

它能稳定识别的，是明确违反 OWASP Top 10 的静态模式，比如：

Miller CSV TSV JSON 数据处理器

Miller (mlr) 是一个命令行工具，用于查询、整形和重新格式化名称索引数据，如 CSV、TSV、JSON 和 JSON Lines。它将 awk、sed、cut、join 和 sort 的功能整合到一个专为结构化数据处理而构建的单一工具中。

下载

• child_process.exec(cmd + userInput) → 触发 security/detect-child-process
• res.send(req.query.callback + '("ok")') → 触发 security/detect-object-injection
• new Function(userInput) → 触发 security/detect-new-function

但它不会发现 if (user.role === 'admin') { deleteOrder() } 这类逻辑漏洞——没有业务注释或 OpenAPI 定义，工具无法知道“删除订单”是否该受角色约束。

容易被忽略的兼容性陷阱

安全规则依赖 AST 解析精度，以下情况会导致漏报或崩溃：

• 项目使用 export default class X extends Y 但 ESLint 配置里没设 "ecmaVersion": 2022，部分规则直接跳过
• 混用 overrides 时，若某子目录的 parserOptions 未继承主配置，安全规则可能失效
• VSCode 使用的是 workspace 级 ESLint，而非项目级；如果 .vscode/settings.json 里指定了错误的 eslint.packageManager（比如设成 yarn 但项目用 pnpm），插件会静默失败

真正卡住人的从来不是“有没有插件”，而是规则是否被实际加载、AST 是否完整、以及你写的那行危险代码，是否恰好落在工具能建模的模式边界内。