network-request-auditing

网络请求审计

使用 cursor-ide-browser MCP 深入检查网络健康状况。这项技能侧重于 browser_network_requests，不只是检查“有没有 500 错误”，还要找出可能表明存在 Bug、浪费或安全问题的模式。

工作原理

1. 在浏览器中操作应用（导航、点击、提交表单），触发真实请求。
2. 在有意义的交互之后（以及导航完成后）调用 browser_network_requests。
3. 根据以下标准对发现进行分类并报告。

遵循 cursor-ide-browser 工作流规则：进行结构性交互前使用 browser_snapshot；执行会改变页面的操作后，在下次交互前重新获取快照。

审计清单

失败

• 4xx / 5xx — 列出方法、URL（路径 + 查询参数）、状态，以及 UI 是否处理了该错误。
• CORS 或网络错误 — 通常是源配置错误或混合内容导致的。

性能

• 慢请求 — 标记延迟较高的请求（例如，如果可以看到耗时，则服务器耗时 > 500 ms；否则注明异常庞大的瀑布流）。
• 重复调用 — 同一用户操作中多次触发相同 URL + 方法的请求（通常由 React effect 或缺少去重导致）。
• 超大载荷 — 响应对于 UI 的需求而言似乎过大（建议采用分页、字段选择或压缩）。

安全与隐私

• URL 中包含敏感数据 — 查询字符串中包含令牌或 PII。
• 缺少身份验证 — 应发送凭据或 bearer token 的 API 调用却未发送（与相邻的已验证调用进行比较）。

正确性

• 意外的主机 — 调用了功能文档中未说明的第三方服务（跟踪器、意外泄露）。
• 预检风暴 — 过多的 OPTIONS 请求可能表明 CORS 缓存配置错误，或存在过多不同的源。

步骤

1. 从全新导航开始 — 使用 browser_navigate 导航到目标 URL（或通过 browser_tabs 使用现有标签页）。

2. 体验功能 — 执行会触发 API 调用的交互（筛选、无限滚动、保存表单、打开模态框）。

3. 获取网络日志 — 如果页面需要多次往返，则在每个逻辑步骤后调用 browser_network_requests。

4. 报告 — 使用结构化输出：

   • 汇总数量（失败、慢请求、重复组）。
   • 使用表格或项目符号列出问题，包含 URL 模式（不一定要显示完整机密）、状态、类别（失败 / 性能 / 安全 / 正确性）。
   • 建议后续代码更改或调查方向。

说明

• Iframe 流量可能不会出现在同一日志中 — 如果功能运行在 iframe 中，请注明。
• 请与预期的 API 设计进行比较；如果 UI 已妥善处理，那么“可选资源未找到”时的 404 可能是正常的。
• 搭配使用 browser_console_messages，以捕获未体现为 HTTP 失败的错误（例如 200 响应后的解析错误）。