mcp security-testing playwright har qa-automation typescript

使用MCP扫描器将Playwright HAR流量转化为安全检测结果

一种被动的TypeScript扫描工具能够将Playwright的HAR文件转换为关于请求头、Cookie、CORS以及敏感信息的安全问题，并通过MCP和CI流程将这些信息呈现给人工智能。

发布者：REACTAPP.TOP加入本站 2026年10月28日阅读约 7 分钟1645 词

来源: I Built an MCP Security Scanner That Turns QA Traffic Into Security Tests

QA工程师每天都要处理API、HTTP请求、登录流程、浏览器自动化、CI/CD流水线以及应用程序行为。这些工作与应用程序安全高度重叠，这就引出了一个问题：自动化测试产生的流量能否同时作为安全测试的输入？

一个解决方案是使用MCP（模型上下文协议）服务器，它能够扫描记录的测试流量以检测安全问题。整个流程非常简单：运行QA自动化测试，捕获HTTP流量，扫描流量中的问题，再借助人工智能来解读检测结果。值得注意的是，该扫描工具从不向应用程序发送额外的请求。

共享同一数据源的两个领域

安全与质量保障通常被视为独立的环节。质量保障流程包括编写测试用例、运行测试、验证功能完整性以及生成报告。而安全工作则在其他环节进行：运行安全工具、扫描应用程序、排查漏洞并汇报发现的问题。

但实际上，自动化测试早已与应用程序产生交互。它们会调用API、发送认证头和Cookie、接收响应并访问各个端点。所有这些都属于HTTP流量，可作为安全信息的来源。

HAR文件作为桥梁

像Playwright这样的工具能够将浏览器的网络活动保存为HAR（HTTP归档）文件。该文件中的每笔HTTP交易都包含以下详细信息：

请求URL与HTTP方法
请求和响应头信息
Cookie
请求和响应正文
状态码及其他元数据

这样就能形成一个流程：从质量自动化测试开始，最终对由此产生的流量进行扫描：

QA Automation
      │
      ▼
HTTP Traffic
      │
      ▼
    HAR File
      │
      ▼
Security Scanner
      │
      ▼
Security Findings

不会产生新的流量。扫描器仅分析测试已捕获的数据，因此这种方式属于被动型。

架构

该扫描器是一个 TypeScript 工具，用于读取 HAR 文件并查找与安全相关的信号。其结构设计得极为简洁：

Playwright
                        │
                        ▼
                 Network Traffic
                        │
                        ▼
                     HAR File
                        │
                        ▼
                   HAR Parser
                        │
                        ▼
              Normalized Transactions
                        │
                        ▼
                 Security Rules
                   │         │
                   ▼         ▼
                MCP Tool   CLI Gate
                   │         │
                   ▼         ▼
                 AI        CI/CD

一个重要的设计决策是将HAR解析器、标准化事务模型、安全规则以及扫描引擎拆分为独立的模块。只有解析器负责处理HAR格式。安全规则无需了解原始的HAR结构，而是基于标准化的事务进行处理，因此日后添加新规则十分方便。

第一个版本中的检查项

缺少HSTS头信息。扫描工具会标记缺少该头信息的响应：

Strict-Transport-Security

HSTS 能迫使浏览器使用 HTTPS，它是安全配置中非常重要的一部分。

普通 HTTP。通过

http://

而不是

https://

指向在常规测试过程中意外出现的不安全端点。

Cookie属性。会检查Cookie中是否存在保护性标记：

Secure
HttpOnly
SameSite

缺少必要属性的认证或会话 Cookie 需要仔细检查。

响应中的机密类值。 想象这样一个响应：

{
  "apiKey": "..."
}

返回给客户端的看似凭证值的内容可能带来问题。尤其值得关注的是，即便没有专门为检测此问题而设计的安全测试，质量保证测试也可能会偶然发现它。

敏感的 URL 参数。 有时机密信息会出现在 URL 中：

/api/user?token=...

扫描器会检查URL中的参数名称及可能敏感的模式。URL会出现在日志、浏览器历史记录、代理服务器、分析系统等地方，因此这一点非常重要。

信用卡号。这是较为有趣的规则之一。扫描器会识别出看似信用卡号的数值，并使用卢恩算法对其进行验证。随机的16位数字意义不大，但既类似信用卡号又能通过卢恩算法验证的数值，则更有可能表明支付数据已泄露。该规则将模式检测与实际验证相结合。

存在风险的CORS配置。扫描器会查找危险的组合。例如通配符来源地址：

Access-Control-Allow-Origin: *

允许的凭据包括：

Access-Control-Allow-Credentials: true

这值得进一步调查。它还能识别出那些在未经适当验证的情况下就直接回传请求中Origin值的服务器。

让扫描器可被人工智能调用

模型上下文协议是人工智能应用使用外部工具和数据的标准方式。该项目并未将其限制为独立的扫描器，而是将其作为可被人工智能调用的工具来提供。MCP服务器会发布一个工具：

secscan_scan_har

AI客户端提供HAR文件，运行扫描器后即可获得结构化的检测结果。流程如下：

HAR File
                 │
                 ▼
            MCP Server
                 │
                 ▼
          Security Scanner
                 │
                 ▼
          Security Findings
                 │
                 ▼
            AI Client
                 │
                 ▼
        Explain / Investigate

逐行阅读报告已不再是唯一的选择，因为人们可以直接针对检测结果提出问题。常见的疑问包括哪些发现的风险等级最高、哪些与身份验证相关，或是为何某种特定的CORS配置存在风险。扫描工具会提供相关证据，而人工智能则负责对其进行解释。

避免让人工智能参与合格/不合格的判定

人工智能擅长解释检测结果、总结数据、协助分析证据、提出修复建议以及回答与扫描相关的问题。不过，实际部署不应取决于模型是否“认为”某系统存在漏洞。因此，该项目还配备了确定性CLI安全关卡：

npm run gate -- test-results/network.har

当出现关键性问题时，扫描器可能会导致构建失败。这有两种不同的处理方式。第一种是人工智能辅助分析：

AI-Assisted Analysis

HAR
 ↓
MCP
 ↓
AI
 ↓
Explain / Investigate / Triage

第二种是确定性安全网关：

Deterministic Security Gate

HAR
 ↓
Scanner
 ↓
Critical Finding?
 ↓
FAIL BUILD

这种区分很重要。在需要推理和交互才能创造价值的场景中使用人工智能，而在必须能够预测通过/失败结果的场景中使用确定性规则。

将其集成到 Playwright 流水线中

假设已有一个包含常规测试步骤的 Playwright CI 任务：

- name: Run Playwright tests
  run: npx playwright test

在其后立即添加一个安全步骤：

- name: Security Gate
  run: npm run gate -- test-results/network.har

同样的质量检测测试现在能生成两种类型的证据：功能测试证据与安全测试证据。整体的工作流程如下：

Code
 │
 ▼
Build
 │
 ▼
Playwright Tests
 │
 ▼
Capture HAR
 │
 ▼
Passive Security Scan
 │
 ▼
Security Gate
 │
 ▼
Deploy

这正是该方案最吸引人的地方。并非每个基础信号都需要独立的安保工作流程，因为某些检查可以在现有的质量保障流程中自然完成。

棘手的设计问题

编写MCP服务器并非难点，真正的难题在于如何设计HAR解析器与安全规则之间的数据结构。HAR是一种结构复杂的格式，如果每条规则都必须直接理解它，维护工作将会变得极为困难。采用中间表示形式就能解决这个问题：

HAR
 │
 ▼
Parser
 │
 ▼
Transaction
 │
 ▼
Security Rules

规则并不关心交易起源于何处。它们接收的是自己已经能够理解的内容，这使得扫描器更易于扩展。

未来可能的发展

这只是一个初始版本，还有很大的发展空间。目前的检测项目包括：

内容安全策略分析
X-Content-Type-Options与Referrer-Policy设置
Cache-Control相关问题
JWT信息泄露风险
认证与会话机制的弱点
敏感数据泄露问题
更多CORS相关检测
授权相关的信号分析

检测结果还可以包含更丰富的证据信息，格式如下：

Finding
Severity
Rule
Evidence
Request
Response
Impact
Remediation

MCP层最终或许能够回答诸如“哪些问题应优先调查？”、“多个问题是否由同一配置问题导致？”以及“如何向开发人员解释这一发现？”之类的问题。

CI集成是另一个发展方向：GitHub Actions、拉取请求中的安全评论、SARIF输出、严重性阈值、基线问题检测以及安全退化问题的识别。其目标是让安全测试看起来像是又一个质量检查环节，而非一个独立的体系。

为何质量保障人员最为合适

质量保证工程师日常工作的很多内容也是应用程序安全的核心：HTTP、API、身份认证与授权、测试自动化、CI/CD、应用程序行为与故障分析。通过开发工具，能够比单纯依靠课程或证书获得更深入的理解。这类项目会依次涉及HAR解析、HTTP安全、Cookie、CORS、机密数据与敏感数据检测、安全规则、MCP、CLI接口以及CI/CD等内容。

其价值远不止于多了一个代码仓库：它展示了如何将质量保证自动化数据转化为安全情报。测试已经能够监控应用程序行为，HAR文件以结构化形式记录这些行为，规则可从流量中提取有用信息，而MCP则让AI客户端具备相应功能。这些要素共同构成一个完整的理念：

QA Automation
      +
Application Security
      +
AI
      +
DevSecOps

核心要点在于，安全测试不必从另一轮扫描开始，而可以借助已有的流量测试来启动。质量保障自动化、应用安全、人工智能以及 DevSecOps 相结合，其潜力与覆盖范围可能远超单独使用其中任何一项技术。