我用 Chrome 扩展验证了 MCP 的安全风险，结果发现

前言

作为一名前端开发，我想探索浏览器能和 MCP 服务交互到什么程度。受 Koi.ai 文章启发做了个 Chrome 扩展，意外发现：前端与本地 MCP 的交互场景比想象的要有限，但这个探索过程揭示了更多有趣的技术可能性。

起因：一个有趣的技术问题

作为一名前端开发工程师，我最近一直在关注 MCP (Model Context Protocol) 这个新兴协议。它让 AI 应用能够与各种工具和数据源交互，为前端领域带来了很多新的想象空间。

某天读到 Koi.ai 的一篇研究文章 Trust Me, I'm Local: Chrome Extensions, MCP, and the Sandbox Escape，文章从安全角度指出 Chrome 扩展可以访问本地运行的 MCP 服务器。但对我来说，这个技术细节引发了更多关于前端能力边界的思考：

我想探索的问题：

• 前端（Chrome 扩展）能和 MCP 交互到什么程度？
• 这种交互机制能带来什么样的解决方案？
• 浏览器沙箱和本地服务的边界在哪里？
• 是否存在前端直接调用本地 MCP 的实用场景？

原文的安全视角

简单介绍一下原文背景：Koi.ai 是一家专注于软件供应链安全的公司，他们的研究团队发现 Chrome 扩展可以扫描并连接到本地 MCP 服务器。如果服务器无认证，可能访问文件系统、Slack 等敏感资源。文章的核心观点是：

"任何 Chrome 扩展都可以利用这个。不需要特殊权限。"

但作为前端开发，我的第一反应不是"这很危险"，而是"这很有趣" ------这不正好说明前端技术栈有了新的能力边界吗？带着技术探索的好奇心，我决定：

1. 动手实现一个 Chrome 扩展探索这个边界
2. 了解前端与 MCP 交互的技术细节
3. 评估这种交互模式的实用价值
4. 顺便考虑一下安全性问题

实践：动手探索前端与 MCP 的边界

作为前端开发，最好的学习方式就是动手做。我花了几天时间实现了一个 Chrome 扩展：

技术实现：

• Chrome Extension Manifest V3（前端标准）
• 后台 Service Worker 扫描本地端口
• Fetch API 探测 SSE 和 Streamable HTTP 端点
• JSON-RPC 2.0 协议交互
• 测试用的 MCP 服务器（Express.js）

扫描逻辑：

// 尝试连接 localhost 的常见端口
const ports = [3000, 3001, 5173, 8080, ...];
const endpoints = ['/sse', '/mcp', '/api/mcp'];

// 1. 尝试 SSE 连接
const sseResponse = await fetch(`http://localhost:${port}/sse`, {
  method: 'GET',
  headers: {'Accept': 'text/event-stream'}
});
if (sseResponse.headers.get('content-type')?.includes('text/event-stream')) {
  const sessionId = sseResponse.headers.get('x-session-id');
  console.log('Found SSE MCP server with session:', sessionId);
}

// 2. 尝试 Streamable HTTP 连接
const httpResponse = await fetch(`http://localhost:${port}/mcp`, {
  method: 'POST',
  headers: {'Content-Type': 'application/json'},
  body: JSON.stringify({
    jsonrpc: '2.0',
    method: 'initialize',
    params: {
      protocolVersion: '2024-11-05',
      capabilities: {},
      clientInfo: {name: 'Scanner', version: '1.0.0'}
    },
    id: 1
  })
});
const data = await httpResponse.json();
if (data.jsonrpc === '2.0' && data.result) {
  console.log('Found HTTP MCP server:', data.result.serverInfo);
}

测试很成功！扩展完美检测到了测试服务器，前端可以流畅地完成：扫描本地端口 → 建立 MCP 连接 → 获取工具列表 → 调用 MCP 工具。

技术验证完成：前端确实可以和本地 MCP 交互！

发现：但实际场景远比想象的有限

就在我准备为这个"新能力"兴奋时，一个问题让我冷静下来：作为前端开发，我们真的会在 localhost 运行 HTTP 模式的 MCP 服务器吗？

这个问题引发了我对 MCP 实际部署模式的思考。让我先解释一下 MCP 支持的三种传输方式。

MCP 的三种传输模式详解

MCP 协议设计上支持三种传输方式，每种都有不同的使用场景：

1. stdio 模式（主流方式）

{
  "mcpServers": {
    "filesystem": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-filesystem", "/path"]
    }
  }
}

特点：

• 通过标准输入输出通信
• 作为子进程运行，不开放网络端口
• Chrome 扩展完全无法访问 ✅
• 这是 Claude Desktop 等主流应用的标准配置

安全性：高 - 天然隔离，Chrome 扫描不到

2. Server-Sent Events (SSE) 模式

特点：

• GET 请求建立 SSE 连接，服务器可推送事件
• POST 请求发送 JSON-RPC 消息（双向通信）
• 需要开放 HTTP 端口，使用 session ID 管理连接

3. Streamable HTTP 模式

特点：

• 基于标准 HTTP POST 请求，使用 JSON-RPC 2.0 协议
• 无状态设计，每次请求独立（无需 session）
• 更简单直接，易于部署和集成

关键发现：网络模式实际部署在哪？

理解了三种传输模式后，一个更重要的问题浮现出来：SSE 和 Streamable HTTP 这两种网络传输模式，在实际项目中是怎么部署的？

情况 A：生产部署（常见）

• 部署在远程服务器（mcp.example.com）
• 有认证机制（API Key、OAuth 等）
• Chrome 扫描不到（不在 localhost）

情况 B：本地开发测试（较少）

• localhost:3001
• 可能无认证（为了方便测试）
• Chrome 可以扫描
• 但通常是临时的，开发测试完就关闭

实际使用场景分析

场景	传输模式	普遍性	Chrome 可访问	实际风险
Claude Desktop 等	stdio	⭐⭐⭐⭐⭐	❌	无
远程 MCP 服务	SSE/HTTP	⭐⭐⭐	❌	无
本地开发测试	SSE/HTTP	⭐	✅	低

注：普遍性基于 MCP 官方推荐和主流工具的实际采用情况，非精确统计数据。

看到这个表格，答案很明显：真正能被 Chrome 扩展访问到的本地 MCP 场景非常少见。原文描述的安全风险，在实际中发生的概率很低。

这让我意识到：虽然技术上验证了前端可以和本地 MCP 交互，但实用场景确实有限。那这个项目还有意义吗？

转型：从 MCP 探索到开发环境工具

答案是有的！当我跳出最初"前端连接 MCP"的设定，重新审视手上的代码时，发现了新的价值点。

从 ：探索前端与 MCP 的交互边界
到：开发环境服务发现工具

想想看，作为前端开发，我们的日常工作中经常会遇到这样的情况：

• 同时运行多个开发服务器（Vite、webpack-dev-server）
• 本地启动数据库（MongoDB、Redis）
• 开启各种调试端口
• 忘记关闭测试服务

而我手上这个扫描器，恰好可以帮助解决这些问题：

• 扫描并列出所有本地运行的开发服务
• 识别服务类型（根据端口和响应）
• 提醒可能的安全风险
• 生成本地服务清单

这次探索的收获：

技术层面：

• 理解了浏览器扩展的能力边界
• 掌握了 Chrome Extension API
• 实践了 MCP 协议细节
• 学会了端口扫描的前端实现

实用层面：

• 快速查看本地运行了哪些服务
• 清理被遗忘的测试服务
• 团队共享开发环境配置

虽然和最初"探索前端 MCP 能力"的目标不同，但这个方向显然更实用。这让我想起了一个词：Pivot（战略转向）------保留已有成果，找到新的价值点。

拓展：国内智能体的安全设计对比

既然聊到了 MCP 的安全性，作为国内开发者，我也想聊聊国内智能体平台在架构安全上的差异。

快速对比

平台	部署模式	本地集成	安全特点
字节豆包	云端为主	较少	企业级权限
百度文心	云端 + 私有化	中等	完善审计
阿里通义	云端 + 本地	支持	依赖配置
智谱清言	API + 本地	支持	企业方案
纳米AI	本地优先	完整	安全基因 ✅

纳米AI的差异化优势

通过这次 MCP 安全探索，我发现纳米AI在架构设计上有些不同的思考：

核心设计理念：

• 默认 stdio 通信：和 Claude 一样，优先用进程间通信，避免网络暴露风险
• 完全私有化部署：企业可内网部署，数据不出边界，满足合规要求
• 细粒度权限控制：每个工具都有明确权限范围，支持多层认证（API Key、OAuth、SSO）
• 安全审计完整：所有工具调用都有日志，内置配置审计工具

为什么值得关注：

1. 从设计之初就考虑本地安全（而不是事后补救）
2. 既有国际化的技术标准（如默认 stdio），又适配中国企业需求
3. 开发者生态友好，提供安全配置模板和最佳实践

一句话总结 ：在 MCP 安全问题日益受关注的今天，纳米AI这种"安全优先"的设计理念，比"功能优先，安全后补"更值得信赖。

总结：一次完整的技术探索

关于前端与 MCP 的交互

回到最初的问题：前端能和 MCP 交互到什么程度？

技术验证的结果：

• ✅ Chrome 扩展可以访问 localhost 的 MCP 服务器
• ✅ 可以通过 Fetch API 发送 JSON-RPC 请求
• ✅ 可以建立 SSE 连接接收事件
• ✅ 可以调用 MCP 提供的工具

实际上受限的：

• ❌ MCP 官方推荐并被主流工具采用的是 stdio 模式（前端无法访问）
• ❌ HTTP 模式主要在远程（有 CORS 和认证）
• ❌ 本地 HTTP 模式较少见（主要用于开发测试，且临时）
• ❌ 缺少实用的前端直连本地 MCP 场景

这次探索的收获

虽然最初"前端直连本地 MCP"的设想场景有限，但这次探索本身很有价值：

技术收获：

• 深入理解了 MCP 协议（三种传输模式）
• 学会了浏览器中的端口扫描实现
• 理解了浏览器安全模型的边界

实用产出：

• 开发环境服务发现工具
• 可以帮助团队管理本地服务
• 可以作为 MCP 开发调试工具

思维层面：

• 学会从多个视角看待同一个技术现象
• 理解技术可行性和实际价值的区别
• 掌握了 Pivot（调整方向）的方法
• 培养了批判性思考技术文章的能力

---

项目开源

GitHub 仓库 ：github.com/donghai88/m...

完整代码已开源，包含 Chrome 扩展、测试 MCP 服务器。欢迎 Fork、Star 或提 Issue 讨论！

欢迎前端同学交流：

• 你怎么看前端与 MCP 的集成？有没有好的实践案例？
• 你遇到过类似"技术可行但场景有限"的探索吗？
• 对这个项目有什么改进建议或新想法？

---

参考资料：

• Koi.ai - Trust Me, I'm Local
• MCP Protocol Specification
• Chrome Extension Security
• 纳米AI 官网

---

声明：

• 本文从前端开发视角探讨 MCP 技术，补充了 Koi.ai 原文的安全研究视角
• 感谢原作者 Yuval Ronen 的研究工作，为技术社区提供了宝贵的安全洞察
• 对国内智能体平台的评价基于公开信息和个人使用体验

我相信技术探索需要多元视角------安全研究员看到风险，开发者看到可能性，产品人看到价值。这些视角互补，才能让技术生态更健康。欢迎不同背景的同学一起讨论！ 🤝