1. 项目概述：为什么我们需要关注JavaScript的“四类核心风险”？

最近在带一个前端安全方向的实训项目，团队里几个同学在写业务代码时，总问我：“老师，我们写的JavaScript代码，除了功能实现，到底还有哪些地方容易出安全问题？感觉每次代码审查，提的都是些格式问题。” 这其实是个很普遍的现象。很多开发者，尤其是刚入行的朋友，对JavaScript的安全风险认知，往往停留在“不要用 eval ”、“小心XSS”这种零散的知识点上，缺乏一个系统性的、可实操的检测框架。

这就是我们这次实训项目——“JavaScript四类核心风险轻量检测”要解决的问题。它不是一个庞大的、需要集成到CI/CD的复杂安全扫描工具，而是一个 轻量级、可快速上手、能直接嵌入到你日常开发流程中的风险自查清单和检测脚本集 。它的核心目标是：让你在提交代码前，花几分钟跑一下，就能对代码中潜藏的几类高风险问题有个清晰的把握，而不是等到上线后被安全团队揪出来，或者更糟——被攻击者利用。

那么，这“四类核心风险”具体指什么？简单来说，它们是前端JavaScript代码中最常见、也最容易被忽视的安全“雷区”：

1. 代码注入与执行风险 ：比如动态代码执行、不安全的反序列化。
2. 敏感信息泄露风险 ：比如硬编码的密钥、API令牌、调试信息泄露。
3. 依赖与供应链风险 ：比如使用了已知漏洞的第三方库、未锁版本的依赖。
4. 客户端逻辑缺陷风险 ：比如不安全的直接DOM操作、客户端敏感逻辑验证绕过。

这个项目的价值在于“轻量”和“核心”。我们不做大而全的代码审计，而是聚焦于这四类最高频、危害最大的问题，提供一系列简单的脚本、正则表达式匹配和最佳实践检查点。无论你是个人开发者维护一个小项目，还是团队中想提升代码安全水位，这套方法都能让你用最小的成本，获得显著的安全收益。

2. 核心风险拆解：四类问题的深度剖析与真实案例

在动手写检测脚本之前，我们必须彻底理解每一类风险的本质、常见的表现形式以及它们可能造成的实际危害。只有理解了“为什么”，我们才能更好地设计“怎么查”。

2.1 第一类风险：代码注入与执行风险

这是JavaScript安全的老大难问题，根源在于 混淆了代码与数据 。当用户输入或外部数据被当作代码的一部分执行时，风险就产生了。

核心原理 ：JavaScript提供了多个动态执行代码的接口，如 eval() 、 Function() 构造函数、 setTimeout() / setInterval() 中传入字符串、以及 innerHTML 赋值中嵌入的 <script> 标签等。如果这些接口的参数中包含了未经验证或转义的外部数据，攻击者就能注入任意JavaScript代码。

典型场景与检测点 ：

• 直接 eval 用户输入 ： eval(userInput) 这是最危险的模式。
• 间接动态执行 ： new Function('return ' + urlParams.id)() ， 通过 Function 构造器执行拼接的字符串。
• 定时器中的字符串 ： setTimeout("alert('" + msg + "')", 1000) ， 字符串拼接后作为代码执行。
• 不安全的反序列化 ：直接使用 JSON.parse 解析不可信的字符串本身风险较低，但若解析后的对象被用于不安全的行为（如配合 eval ），或使用了不安全的序列化库（如早期的 eval 式序列化），也会带来问题。更危险的是类似 node-serialize 这类库曾出现的原型链污染漏洞，可通过特殊构造的JSON对象触发。

实操心得 ：现代前端开发中，直接使用 eval 的情况已大大减少，但风险转移到了更隐蔽的地方。比如，一些模板引擎在早期版本或错误配置下，可能允许执行表达式；或者一些为了“灵活”而动态生成并插入 <script> 标签的代码。检测时，不仅要搜索 eval 和 Function ，还要关注 setTimeout / setInterval 、 document.write 、 innerHTML / outerHTML 赋值中是否存在未转义的变量拼接。

2.2 第二类风险：敏感信息泄露风险

“把钥匙藏在脚垫下”是安全的大忌，但在代码里，我们却经常无意中这么做。这类风险指的是将本应保密的信息（如API密钥、数据库密码、加密盐值、内部服务地址）直接以明文形式写在客户端JavaScript代码中。

核心原理 ：前端代码（HTML、JS、CSS）对用户是透明的。任何部署到客户端的秘密，都不再是秘密。攻击者可以通过浏览器的开发者工具（Sources, Network, Console）轻易地提取这些信息。

典型场景与检测点 ：

• 硬编码的API密钥/令牌 ： const apiKey = 'sk_live_xxxxxxxxxxxx'; 直接出现在 .js 文件中。
• 完整的后端服务URL包含凭证 ： const dbUrl = 'http://username:password@internal.db.com:5432';
• 调试信息未移除 ： console.log('User token:', user.authToken); 在生产环境中未删除。
• 源代码注释中的敏感信息 ：在注释里不小心留下了测试用的密码或密钥。
• 前端配置文件中包含后端信息 ：在 config.js 或环境变量文件（如 .env ）被意外打包到客户端时，其中包含的敏感变量。

注意事项 ：很多人认为使用环境变量（ process.env ）在前端是安全的，但这取决于构建工具。像Webpack等工具在构建时会将 process.env.XXX 替换为对应的字符串值， 这个值最终会明文出现在打包后的代码中 。因此，绝对敏感的信息（如数据库密码、支付密钥）必须由后端保管，前端只能持有用于标识自身或访问公开资源的非敏感令牌。

2.3 第三类风险：依赖与供应链风险

现代前端开发离不开 npm ，但“免费的午餐”可能暗藏毒药。你引入的一个小小的工具函数库，可能依赖了一个存在严重漏洞的底层库。这就是供应链风险。

核心原理 ：项目依赖树庞大且复杂，你直接依赖的包（一级依赖）可能又依赖了数十个其他包（传递依赖）。其中任何一个包被植入恶意代码（投毒）或存在未修复的已知漏洞，都会影响到你的项目。

典型场景与检测点 ：

• 使用含有已知漏洞的库版本 ：例如，某个UI组件库依赖的 lodash 版本存在原型污染漏洞(CVE-2020-8203)。
• 依赖版本锁定不严格 ： package.json 中使用了模糊版本号如 ^1.0.0 （兼容版本），导致不同环境或不同时间安装时，可能安装到含有新引入问题的次要版本。
• 依赖了不再维护的包 ：该包可能含有未修复的漏洞，且无人响应。
• 包来源不可信 ：使用了非官方源（npm registry）或从不明来源直接复制代码。

检测手段 ：这部分的检测通常不是通过扫描业务代码，而是通过分析 package.json 、 package-lock.json / yarn.lock 以及 node_modules 的元数据来完成。我们需要关注依赖的版本和已知漏洞数据库（如NVD、npm audit）的匹配情况。

2.4 第四类风险：客户端逻辑缺陷风险

这类风险源于一个错误的假设：“前端代码只是用来展示的，核心逻辑安全由后端保证”。虽然后端校验至关重要，但完全依赖后端而忽视前端逻辑的健壮性，会导致糟糕的用户体验和潜在的安全旁路。

核心原理 ：攻击者可以完全控制浏览器环境。他们可以禁用JavaScript、修改内存中的变量、拦截并篡改网络请求、或者直接使用开发者工具动态修改DOM和CSS。如果前端逻辑存在缺陷，可能为攻击者提供绕过客户端限制、探测系统信息或发起不当请求的途径。

典型场景与检测点 ：

• 仅靠前端验证 ：例如，仅用JavaScript验证表单输入格式，而后端没有做同样的校验，攻击者可以直接发送恶意构造的POST请求。
• 不安全的DOM操作 ：使用 innerHTML 直接插入未转义的用户输入，导致XSS（这其实也属于第一类风险，但更常见于DOM操作场景）。应优先使用 textContent 或安全的DOM API。
• 客户端敏感逻辑判断 ：例如，将用户角色（ user.role = 'admin' ）或权限标志存储在客户端JavaScript对象中，并仅凭此决定是否显示某个管理按钮。攻击者可以轻易修改这个变量。
• 错误信息泄露过多 ：网络请求失败时，将完整的后端错误堆栈返回给前端并展示给用户，可能泄露服务器路径、数据库类型、SQL语句片段等敏感信息。

实操心得 ：这类风险的检测更像是一种“逻辑审计”。我们需要审视代码：有哪些操作是假设只能在特定条件下由用户触发？这些条件是否完全由前端状态控制？是否有任何敏感决策点（如“是否显示删除按钮”）是基于一个前端可篡改的变量？记住黄金法则： 任何来自客户端的输入和状态都不可信，包括URL参数、Cookie、LocalStorage、以及内存中的JavaScript变量 。

3. 轻量检测方案设计与实现

理解了风险，接下来就是构建我们的“轻量检测器”。所谓轻量，体现在两个方面：一是 检测逻辑本身简单、聚焦 ，不引入复杂的语法分析树（AST）解析（虽然那更强大）；二是 易于集成 ，可以是一个命令行脚本、一个Git钩子（pre-commit）、或者一个简单的构建插件。

我们的方案核心是： 基于正则表达式（Regex）的模式匹配 + 依赖文件分析 + 简单的静态代码扫描 。对于更复杂的场景，可以辅以简单的AST解析（例如使用 @babel/parser ），但为了保持轻量，我们优先使用正则。

3.1 检测工具选型与项目结构

我们选择Node.js环境来编写检测脚本，因为它与前端开发环境天然契合，可以方便地读取文件、执行命令。

项目基础结构 ：

js-risk-detector/
├── package.json
├── detector.js          # 主检测脚本
├── rules/              # 检测规则库
│   ├── injection.js    # 代码注入规则
│   ├── secrets.js      # 敏感信息规则
│   ├── dependencies.js # 依赖风险规则
│   └── client-logic.js # 客户端逻辑规则
├── patterns.json       # 正则表达式模式合集（可选，集中管理）
└── test-files/         # 用于测试的样例代码文件

关键工具库 ：

• fs / path ：Node.js内置模块，用于文件遍历。
• child_process ：用于执行 npm audit 等外部命令。
• @babel/parser (可选)：如果需要更精准地检测代码结构（而非简单文本匹配），可以引入它来将代码解析为AST，然后进行遍历分析。对于轻量级方案，我们初期可以不用。

3.2 第一类风险检测：代码注入模式匹配

我们编写 rules/injection.js ，定义一系列高风险模式的正则表达式。

// rules/injection.js
module.exports = {
  name: '代码注入与执行风险',
  patterns: [
    {
      id: 'EVAL_DIRECT',
      description: '直接使用eval函数，且参数包含变量',
      // 匹配 eval( 后面不是纯字符串字面量的情况，简单示例，实际需要更精细
      regex: /eval\s*\(\s*[^'"].*?\)/gs,
      severity: 'HIGH'
    },
    {
      id: 'FUNCTION_CONSTRUCTOR',
      description: '使用Function构造函数动态生成函数',
      regex: /new\s+Function\s*\(/g,
      severity: 'HIGH'
    },
    {
      id: 'SETTIMEOUT_STRING',
      description: 'setTimeout/setInterval第一个参数为字符串字面量拼接',
      // 匹配 setTimeout("字符串" + var, ...)
      regex: /set(?:Timeout|Interval)\s*\(\s*["'].*?\+\s*[a-zA-Z_$][\w$]*/g,
      severity: 'MEDIUM'
    },
    {
      id: 'DANGEROUS_HTML_ASSIGNMENT',
      description: '使用innerHTML/outerHTML直接赋值未处理的内容',
      // 这是一个启发式规则，匹配 .innerHTML = 后面跟着一个变量名
      regex: /\.(?:inner|outer)HTML\s*=\s*([a-zA-Z_$][\w$]*)(?!\s*\.)/g,
      severity: 'MEDIUM',
      note: '需结合上下文判断该变量是否来自用户输入。'
    }
  ],
  // 一个简单的检测函数示例
  detect: function(codeContent, filePath) {
    const issues = [];
    this.patterns.forEach(pattern => {
      let match;
      while ((match = pattern.regex.exec(codeContent)) !== null) {
        issues.push({
          ruleId: pattern.id,
          description: pattern.description,
          severity: pattern.severity,
          match: match[0],
          line: (codeContent.substring(0, match.index).match(/\n/g) || []).length + 1,
          file: filePath
        });
        // 避免在全局正则匹配时陷入无限循环
        if (pattern.regex.lastIndex === match.index) {
          pattern.regex.lastIndex++;
        }
      }
    });
    return issues;
  }
};

实现要点 ：

1. 正则的精确性与性能 ：编写正则表达式是一门艺术。过于宽泛会产生大量误报（如匹配到 eval('true') ），过于严格又会漏报。我们的策略是 先抓取潜在风险点，再通过人工或更高级的规则（如判断变量来源）进行二次筛选 。在轻量检测中，我们倾向于“宁可误报，不可漏报”高危项。
2. 行号计算 ：提供问题所在的行号对于开发者定位问题至关重要。我们通过计算匹配索引前的换行符数量来近似得到行号。
3. 严重等级 ：区分 HIGH 、 MEDIUM 、 LOW ，帮助开发者优先处理最关键的问题。

3.3 第二类风险检测：敏感信息模式匹配

检测硬编码秘密更像是在“大海捞针”，因为秘密的格式千变万化。我们主要依赖两类模式： 已知格式的秘密 和 可疑的赋值模式 。

// rules/secrets.js
module.exports = {
  name: '敏感信息泄露风险',
  patterns: [
    {
      id: 'AWS_ACCESS_KEY',
      description: '疑似AWS访问密钥ID',
      // AKIA后跟20位大写字母和数字
      regex: /AKIA[0-9A-Z]{16}/g,
      severity: 'CRITICAL'
    },
    {
      id: 'GENERIC_API_KEY',
      description: '通用的API密钥模式 (key, token, secret)',
      // 匹配类似 apiKey: '...', token: "..." 的赋值，值看起来像随机字符串
      regex: /(?:api[_-]?key|token|secret|password|passwd|auth)\s*[:=]\s*['"`]([0-9a-zA-Z!@#$%^&*()_+\-=\[\]{}|;:,.<>?/~]{12,})['"`]/gi,
      severity: 'HIGH',
      note: '此规则误报率较高，主要提醒开发者审查此类赋值。'
    },
    {
      id: 'HARDCODED_URL_WITH_CREDS',
      description: 'URL中包含用户名密码',
      regex: /https?:\/\/[^:@\s]+:[^:@\s]+@[^\s'"]+/g,
      severity: 'CRITICAL'
    },
    {
      id: 'CONSOLE_LOG_SENSITIVE',
      description: 'console.log输出可能敏感的关键字',
      regex: /console\.(?:log|warn|error|info)\([^)]*(?:token|key|secret|password|auth)[^)]*\)/gi,
      severity: 'MEDIUM'
    }
  ],
  detect: function(codeContent, filePath) {
    // 检测逻辑与injection.js类似
    const issues = [];
    this.patterns.forEach(pattern => {
      const matches = codeContent.match(pattern.regex);
      if (matches) {
        matches.forEach(match => {
          issues.push({
            ruleId: pattern.id,
            description: pattern.description,
            severity: pattern.severity,
            match: match.substring(0, 100), // 只截取前100字符避免输出过长
            line: this._getLineNumber(codeContent, codeContent.indexOf(match)),
            file: filePath
          });
        });
      }
    });
    return issues;
  },
  _getLineNumber: function(text, index) {
    return text.substring(0, index).split('\n').length;
  }
};

重要提示 ：敏感信息检测的误报率极高。一个变量名 apiKey 并不一定代表它存储了真正的密钥，可能只是一个空字符串或占位符。因此，这类检测的结果 必须由开发者人工复核 ，其核心价值在于“提醒”，而非“判定”。

3.4 第三类风险检测：依赖漏洞扫描

这部分检测主要通过与 npm 或 yarn 的交互来完成，而不是扫描源代码。

// rules/dependencies.js
const { execSync } = require('child_process');
const fs = require('fs');
const path = require('path');

module.exports = {
  name: '依赖与供应链风险',
  detect: function(projectPath) {
    const issues = [];
    const packageJsonPath = path.join(projectPath, 'package.json');

    if (!fs.existsSync(packageJsonPath)) {
      return issues;
    }

    // 1. 检查是否有package-lock.json或yarn.lock
    const hasLockFile = fs.existsSync(path.join(projectPath, 'package-lock.json')) ||
                       fs.existsSync(path.join(projectPath, 'yarn.lock'));
    if (!hasLockFile) {
      issues.push({
        ruleId: 'NO_LOCK_FILE',
        description: '项目缺少锁文件(package-lock.json或yarn.lock)，依赖安装版本可能不一致，存在潜在风险。',
        severity: 'MEDIUM',
        file: 'package.json'
      });
    }

    // 2. 检查package.json中的版本声明是否过于宽松
    const packageJson = JSON.parse(fs.readFileSync(packageJsonPath, 'utf8'));
    const deps = { ...packageJson.dependencies, ...packageJson.devDependencies };
    Object.entries(deps).forEach(([pkgName, versionRange]) => {
      // 过于宽松的版本范围：^, ~, *, >, >=, <, <=, x
      if (/^[\^~*>=<]|x$/i.test(versionRange)) {
        issues.push({
          ruleId: 'LOOSE_VERSION',
          description: `依赖 "${pkgName}" 使用了宽松的版本范围 "${versionRange}"，建议在锁文件中锁定精确版本。`,
          severity: 'LOW',
          file: 'package.json',
          package: pkgName
        });
      }
    });

    // 3. 执行 npm audit (需要项目目录有node_modules)
    try {
      // 注意：execSync会阻塞，且输出可能很大。生产环境建议使用异步或解析audit的JSON输出。
      const auditResult = execSync('npm audit --json', { cwd: projectPath, encoding: 'utf8', stdio: 'pipe' });
      const auditJson = JSON.parse(auditResult);
      if (auditJson.metadata && auditJson.metadata.vulnerabilities) {
        const vulns = auditJson.metadata.vulnerabilities;
        if (vulns.critical > 0 || vulns.high > 0) {
          issues.push({
            ruleId: 'NPM_AUDIT_CRITICAL',
            description: `npm audit 发现严重漏洞：${JSON.stringify(vulns)}。请运行 \`npm audit fix\` 或手动修复。`,
            severity: 'CRITICAL',
            file: 'package.json'
          });
        }
      }
    } catch (error) {
      // npm audit 可能因为网络或权限问题失败，记录但不阻塞
      issues.push({
        ruleId: 'AUDIT_FAILED',
        description: `执行 npm audit 失败: ${error.message}`,
        severity: 'LOW',
        file: 'package.json'
      });
    }

    return issues;
  }
};

实现要点 ：

1. 锁文件检查 ：这是保证团队和环境间依赖一致性的基础，是供应链安全的第一道防线。
2. 版本范围检查 ： ^1.0.0 允许安装 1.x.x 的最新版，可能包含不兼容的更改或新引入的漏洞。虽然现代语义化版本控制（SemVer）理论上小版本和补丁版本是兼容的，但锁定精确版本（在 package-lock.json 中）是最安全的做法。
3. npm audit 集成 ：直接调用 npm 命令获取漏洞报告是最权威的方式。注意处理命令执行可能失败的情况，并考虑解析其JSON输出以获得更结构化的结果。

3.5 第四类风险检测：客户端逻辑启发式扫描

这类检测最复杂，因为它涉及语义理解。我们主要采用启发式规则，寻找那些“看起来像”仅前端校验或敏感逻辑的点。

// rules/client-logic.js
module.exports = {
  name: '客户端逻辑缺陷风险',
  patterns: [
    {
      id: 'FRONTEND_ONLY_VALIDATION',
      description: '发现疑似仅前端验证的代码模式（需人工确认）',
      // 匹配常见的验证函数名，且附近没有明显的异步提交（如fetch, axios.post）
      // 这是一个非常粗略的启发式规则
      regex: /function\s+(validate|check|verify)\w*\s*\(|\.(validate|check)\s*\(/gi,
      severity: 'LOW',
      note: '此规则仅提示可能存在仅前端验证，需结合代码上下文确认后端是否有对应校验。'
    },
    {
      id: 'SENSITIVE_CLIENT_SIDE_DECISION',
      description: '客户端代码中直接使用疑似权限或角色的字符串进行逻辑判断',
      regex: /(?:user|currentUser)\.(?:role|permission|isAdmin)\s*===\s*['"`]admin['"`]/gi,
      severity: 'MEDIUM'
    },
    {
      id: 'POTENTIAL_DEBUG_INFO_LEAK',
      description: '可能泄露过多信息的错误处理',
      // 匹配将整个error对象直接输出到界面或console.error
      regex: /(?:alert|console\.error|document\.write|\.innerHTML\s*\+?=)\s*\(.*err(or)?\s*\)/gi,
      severity: 'MEDIUM'
    }
  ],
  detect: function(codeContent, filePath) {
    const issues = [];
    this.patterns.forEach(pattern => {
      const matches = codeContent.match(pattern.regex);
      if (matches) {
        matches.forEach(match => {
          issues.push({
            ruleId: pattern.id,
            description: pattern.description,
            severity: pattern.severity,
            match: match.substring(0, 150),
            line: this._getLineNumber(codeContent, codeContent.indexOf(match)),
            file: filePath,
            note: pattern.note
          });
        });
      }
    });
    return issues;
  },
  _getLineNumber: function(text, index) { /* ... 同前 ... */ }
};

实现要点 ：客户端逻辑检测的准确性最低，因为它严重依赖上下文。例如，一个名为 validateForm 的函数内部可能只是做UI提示，真正的提交校验在后端。因此，这类规则的输出 必须明确标注“需人工确认” ，它的作用是充当一个“代码审查助手”，在开发者Review代码时高亮潜在的风险模式。

4. 主检测脚本整合与使用

我们将所有规则整合到一个主脚本 detector.js 中，提供一个统一的入口。

// detector.js
#!/usr/bin/env node

const fs = require('fs');
const path = require('path');
const { promisify } = require('util');
const readdir = promisify(fs.readdir);
const stat = promisify(fs.stat);
const readFile = promisify(fs.readFile);

// 动态加载rules目录下的所有规则
const rulesPath = path.join(__dirname, 'rules');
const ruleFiles = fs.readdirSync(rulesPath).filter(f => f.endsWith('.js'));

const rules = {};
ruleFiles.forEach(file => {
  const ruleName = path.basename(file, '.js');
  rules[ruleName] = require(path.join(rulesPath, file));
});

async function scanFile(filePath) {
  const content = await readFile(filePath, 'utf8');
  const ext = path.extname(filePath).toLowerCase();
  // 只扫描.js, .jsx, .ts, .tsx, .vue等文件，可根据需要扩展
  if (!['.js', '.jsx', '.ts', '.tsx', '.vue', '.js'].includes(ext)) {
    return [];
  }

  let allIssues = [];
  // 应用代码扫描类规则
  if (rules.injection && rules.injection.detect) {
    allIssues = allIssues.concat(rules.injection.detect(content, filePath));
  }
  if (rules.secrets && rules.secrets.detect) {
    allIssues = allIssues.concat(rules.secrets.detect(content, filePath));
  }
  if (rules['client-logic'] && rules['client-logic'].detect) {
    allIssues = allIssues.concat(rules['client-logic'].detect(content, filePath));
  }
  return allIssues;
}

async function walkDir(dir, fileList = []) {
  const files = await readdir(dir);
  for (const file of files) {
    const filePath = path.join(dir, file);
    const fileStat = await stat(filePath);
    if (fileStat.isDirectory()) {
      // 忽略node_modules等目录
      if (file !== 'node_modules' && !file.startsWith('.')) {
        await walkDir(filePath, fileList);
      }
    } else {
      fileList.push(filePath);
    }
  }
  return fileList;
}

async function main() {
  const targetPath = process.argv[2] || '.'; // 默认扫描当前目录
  console.log(`开始扫描目录: ${targetPath}\n`);

  const allIssues = [];

  // 1. 扫描源代码文件
  const sourceFiles = await walkDir(targetPath);
  for (const file of sourceFiles) {
    const issues = await scanFile(file);
    allIssues.push(...issues);
  }

  // 2. 执行依赖扫描（针对整个项目）
  if (rules.dependencies && rules.dependencies.detect) {
    const depIssues = rules.dependencies.detect(targetPath);
    allIssues.push(...depIssues);
  }

  // 3. 输出结果
  if (allIssues.length === 0) {
    console.log('✅ 未发现明显的核心风险问题。');
    process.exit(0);
  }

  console.log(`⚠️  共发现 ${allIssues.length} 个潜在问题：\n`);
  // 按严重程度排序
  const severityOrder = { CRITICAL: 0, HIGH: 1, MEDIUM: 2, LOW: 3 };
  allIssues.sort((a, b) => severityOrder[a.severity] - severityOrder[b.severity]);

  let lastFile = '';
  allIssues.forEach(issue => {
    if (issue.file !== lastFile) {
      console.log(`\n📄 ${issue.file}:`);
      lastFile = issue.file;
    }
    const severityTag = `[${issue.severity}]`;
    console.log(`  第${issue.line}行: ${severityTag} ${issue.description}`);
    console.log(`      匹配内容: ${issue.match}`);
    if (issue.note) console.log(`      注意: ${issue.note}`);
    console.log(`      规则ID: ${issue.ruleId}\n`);
  });

  // 根据最高严重程度决定退出码，可用于CI/CD流程
  const highestSeverity = allIssues.map(i => i.severity).sort((a,b) => severityOrder[a] - severityOrder[b])[0];
  if (['CRITICAL', 'HIGH'].includes(highestSeverity)) {
    console.log('\n❌ 发现严重或高危问题，请立即处理！');
    process.exit(1);
  } else {
    console.log('\n🔶 发现中/低危问题，建议尽快审查。');
    process.exit(0);
  }
}

main().catch(console.error);

使用方式 ：

1. 将整个项目克隆到本地。
2. 在需要检测的项目根目录下，运行： node /path/to/detector.js [目标目录，默认为当前目录]
3. 脚本会遍历目录下的所有JS相关文件，并执行四类风险的检测，最后在控制台输出一份报告。

集成到开发流程 ：

• Git Hook (推荐) : 在项目的 .git/hooks/pre-commit 脚本中调用此检测器。如果发现CRITICAL或HIGH级别问题，则阻止提交。

  #!/bin/sh
  node ./scripts/risk-detector.js ./
  if [ $? -eq 1 ]; then
    echo "代码中存在严重安全风险，提交被阻止。"
    exit 1
  fi
  

• CI/CD Pipeline : 在Jenkins、GitLab CI、GitHub Actions的构建步骤中加入此检测，将结果输出为报告，甚至作为质量门禁。

5. 常见问题、局限性与进阶方向

在实际使用这套轻量检测方案的过程中，你肯定会遇到一些疑问和挑战。这里我总结了一些常见问题和我个人的经验。

5.1 误报与漏报的平衡

问题 ：正则表达式匹配的误报率太高了！比如 apiKey 变量可能只是初始化为空字符串。漏报也让人担心，攻击者会不会用一些奇怪的方式绕过检测？

应对策略 ：

1. 分层检测 ：我们的轻量检测定位是“初筛”。它负责找出所有“疑似”问题，然后交给开发者进行 人工确认 。这是成本与收益的平衡。降低误报率需要引入AST分析，会增加复杂度。
2. 白名单机制 ：可以在检测脚本中引入一个简单的白名单文件（如 .risk-ignore.json ），将已知的误报（例如，一个确实叫 apiKey 但值仅为占位符的常量）记录进去，下次扫描时自动忽略。但需谨慎使用，避免把真正的问题也忽略了。
3. 聚焦高危模式 ：优先优化那些对应 CRITICAL 和 HIGH 级别风险的规则，对于 LOW 级别的规则（如宽松版本号），可以容忍较高的误报，因为它们更多是提醒。

5.2 检测能力的局限性

局限性 ：

1. 无法追踪数据流 ：这是静态正则匹配的最大短板。我们无法知道一个变量 userInput 是否来自 document.cookie 、 URL.searchParams 还是硬编码的字符串。因此，对于 eval(userInput) ，无论 userInput 来源是否安全，我们都会报警。高级的静态分析工具（如Semgrep、CodeQL）可以做到数据流追踪，但配置和使用成本高得多。
2. 无法理解业务逻辑 ：对于“客户端逻辑缺陷”，我们只能基于模式猜测。一个 isAdmin 的布尔值判断，可能只是控制UI显示，真正的权限校验在每次API请求的HTTP头中由后端验证。我们的工具无法区分这一点。
3. 对混淆/压缩代码无效 ：代码经过混淆或压缩后，变量名、函数名都变了，正则模式很可能失效。因此， 检测应在源码上进行 ，而不是生产环境的打包文件。

5.3 如何降低对现有项目的“惊吓度”

问题 ：在一个老项目上首次运行，可能爆出成百上千个问题，团队直接懵了，无从下手。

实操建议 ：

1. 分步实施，设定基线 ：首次运行时，将结果保存为报告，但不作为阻断条件。团队一起Review，将其中确认为“非问题”的加入白名单，将真正的风险项录入工单系统。
2. 设定修复优先级 ：按照风险等级（CRITICAL > HIGH > MEDIUM > LOW）和修复难度进行排序。优先修复那些 高危且易修 的，比如一个硬编码的测试密码。
3. 将检测集成到新代码流程 ：对于存量问题，逐步消化。更重要的是，确保 所有新提交的代码 必须通过检测（通过Git Hook）。这样可以防止问题新增，存量问题随着代码重构和迭代慢慢解决。

5.4 进阶方向：从轻量检测到深度集成

如果项目规模扩大，对安全要求更高，可以考虑以下进阶方向：

1. 引入AST分析 ：使用Babel或TypeScript编译器API将代码解析成抽象语法树。这样可以精准定位函数调用、变量声明、属性访问，大幅降低误报，并能实现简单的数据流分析。
2. 集成专业SAST工具 ：将检测脚本作为初步筛选，然后集成像 SonarQube 、 Semgrep 、 CodeQL 这样的专业静态应用安全测试工具。它们规则库更全，分析更深，但通常需要更复杂的部署和配置。
3. 与依赖扫描工具深度集成 ：使用 npm audit --json 解析输出，或者集成更专业的SCA（软件成分分析）工具，如 Snyk 、 WhiteSource 等，它们能提供更详细的漏洞描述、修复建议和许可证风险分析。
4. 打造IDE插件 ：将检测规则做成VS Code或WebStorm的插件，在开发者编写代码时就实时提示风险，实现“左移”安全。

这套“JavaScript四类核心风险轻量检测”方案，是我在多年项目安全和代码审查中提炼出的最小可行方案。它不追求大而全，而是力求在 五分钟内 给开发者一个关于代码安全状况的“快照”。它的最大价值不在于发现了多少个漏洞，而在于 在团队中建立了一种主动识别前端安全风险的习惯和意识 。当你和你的团队开始习惯在提交前跑一下这个脚本，并认真对待每一个提示时，整个项目的基础安全水位就已经在不知不觉中提升了。安全是一个过程，而不是一个结果，这个轻量检测器，就是启动这个过程的一个很好的扳手。