北京
三年前，我动手写 Papers—— 一个基于模型上下文协议的知识库服务器时，对安全的认知还停留在“照着基础规则来就行”：及时更新依赖、别在代码里写死密钥、启用 HTTPS。那时候我觉得，安全不就是这些嘛，能出什么大事。
可是接下的一千八百多个小时里，生产环境整整断了 95 次电。每一次重启、复盘，都让我头皮发麻。我这才慢慢意识到：MCP 的安全跟常规 REST API 安全根本不是一回事。模型上下文协议独特的运作方式，撕开了传统安全指南根本覆盖不到的新攻击面。
下面就把我从坑里爬出来的第一条教训摊开讲讲 —— 如果你也在搭 MCP 服务器，或许能少走点弯路。
不是 REST，威胁模型得重画
传统 API 的世界里，谁在调用、什么时候调用、为什么调用，都清清楚楚。客户端是已知的应用，用户早早完成认证，请求模式一看就懂。可 MCP 的运转方式完全不同：
- 客户端是 LLM。它会“幻觉”工具调用、参数，甚至虚构出不存在的端点。它不是在点按钮，而是根据上下文“猜”要调哪个函数。
- 间接调用链路。用户不直接喊你的 MCP 服务器，而是对模型说话，模型再去调用服务器。中间没有界面帮你挡住异常输入。
- 工具列表动态发现。每个客户端启动时拉取全部工具定义，Schema 改动可能悄然打瘫对方。反过来，恶意客户端也能借机探测你藏了哪些内部工具。
- 多客户端适配。如果服务器开放给 Claude 桌面版、ChatGPT、OpenClaw 等多个 AI 客户端，就要应对各自独立的鉴权机制和输入处理方式。
于是威胁模型的面孔变了。以往防的是“坏人拿着黑客工具往里闯”，现在对我来说，更大头的风险是“一个完全善意的 LLM，无意间拖垮服务、泄漏情报，或者给滥用拉开一道口子”。不是说不防恶意攻击了，而是复盘那 95 次宕机时我发现，相当一部分事故源自合法大模型的意外误用。
密钥管得松，日志箱里全是金矿
多数 MCP 服务器靠 API 密钥做身份核验，这很自然：简单，所有客户端都认。但怎么管这些密钥，远比想象的棘手。
我当初踩的第一个大雷就在这里：为了迁就不同客户端的传参习惯，我把 API 密钥同时放进了三个位置——请求头 Authorization: Bearer、URL 查询参数、JSON 请求体。当时觉得，“三处都支持，客户端接入更方便嘛”，多贴心啊。
错得离谱。
问题出在查询参数上。代理服务器记一份，CDN 记一份，请求链路里每一环几乎都会把完整 URL 写进日志。这意味着你的 API 密钥堂而皇之地出现在日志文件、监控面板甚至浏览器的访问记录里。一旦用上第三方托管服务，那些日志流向了哪里、谁有权限翻阅，你心里根本没底。
如今回看，早期那种“让密钥到处飞”的做法简直是在给攻击者快递信物。即便没有恶意攻击者，内部运维同学翻日志排查问题时，也可能不经意间触碰到密钥，平白增加暴露风险。后来我把所有非头部的密钥传递方式全部砍掉，只留 Authorization 头这一条路，并强制开启传输加密。日志瞬间干净了，宕机相关的鉴权误报也少了一大截。
这只是第一条教训。MCP 服务器的安全坑还连着好几道深沟，下一条关于工具权限隔离的踩坑记录，我会继续摊开讲。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
