别再让Worker裸奔了workers-mcp的SHARED_SECRET鉴权与安全防护完全清单【免费下载链接】workers-mcpTalk to a Cloudflare Worker from Claude Desktop!项目地址: https://gitcode.com/gh_mirrors/wo/workers-mcpworkers-mcp 是一款把 Cloudflare Worker 变成 Claude Desktop 等 MCP 客户端远程工具的开源工具它通过一条SHARED_SECRET 共享密钥鉴权机制守住入口没有正确密钥的请求一律返回 401 拒绝访问。本文带你彻底搞懂它的鉴权原理并附一份可直接对照的安全检查清单。 先搞懂workers-mcp 是怎么工作的workers-mcp 的核心玩法是你在 Cloudflare Worker 里写普通的 TypeScript 方法构建时它会自动翻译成 MCP 工具暴露给 Claude Desktop、Cursor 等 MCP 客户端。整个链路是这样的本地代理一个 Node.js 服务stdio 传输跑在你的电脑上接收 MCP 客户端的工具调用远程调用它带着Authorization: Bearer SHARED_SECRET请求头向你的 Worker 发起POST /rpc调用云端执行Worker 校验密钥后执行对应方法并返回结果。关键在于第 3 步——你的 Worker URL 是公开的任何人都能打开浏览器直接请求/rpc。SHARED_SECRET 就是那道门禁。⚠️ 为什么你的 Worker 不能裸奔想象一下你把 Worker 部署到https://xxx.workers.dev里面可能挂着数据库连接、AI 模型调用、甚至内部 API。如果没有鉴权等于把所有功能对着公网敞开——恶意调用者可以随意消耗你的配额、读取你的数据甚至把成本账单直接打爆。workers-mcp 把这道防线做成了默认行为而且是硬门禁密钥不对连方法名都拿不到。 SHARED_SECRET 鉴权是如何生效的入口校验一行代码拦截一切未授权请求所有 RPC 流量最终都会汇入同一个代理函数。看 src/modules/Proxy.ts 中的核心逻辑const authorization request.headers.get(Authorization)?.replace(/^Bearer /, ) || if (authorization ! secret || secret.length ! 64) { return new Response(Unauthorized, { status: 401 }) }注意两个安全细节密钥精确比对请求头里的 Bearer Token 必须与SHARED_SECRET完全一致否则立即返回401 Unauthorized长度强制校验密钥必须是 64 位32 字节随机数的十六进制表示弱密钥会被直接拒之门外。只有校验通过后才会解析请求体里的{ method, args }并路由到对应方法。其他路径一律 404——攻击者连探路的空间都没有。密钥从哪来加密级随机生成密钥的生成逻辑在 src/scripts/secret.tsconst random_bytes crypto.randomBytes(32) const random_string random_bytes.toString(hex)它使用 Node.js 的crypto.randomBytes生成 32 字节密码学随机数转为 64 位十六进制字符串——不是Math.random()这类可预测的伪随机暴力破解在数学上不现实。生成后的密钥会写入项目根目录的.dev.vars文件该文件默认不进版本库同时保留文件中其他已有的环境变量不会误伤你的配置。两种部署形态都受保护无论你是把 RPC 方法写在 Worker 本体还是写在 Durable Object 里鉴权都是同一套ProxyToSelfsrc/modules/ProxyToSelf.ts校验密钥后直接在当前 Worker 实例上调用方法ProxyToDOsrc/modules/ProxyToDO.ts校验密钥后再路由到 Durable Object。两者都在fetch第一行就调用Proxy做校验密钥检查永远发生在任何业务逻辑之前。 三步启用 SHARED_SECRET 鉴权如果你已经用npx workers-mcp setup完成了引导式安装密钥其实已经自动生成并上传了见 src/scripts/setup.ts。手动模式下则只需三条命令第 1 步生成密钥npx workers-mcp secret generate在.dev.vars中写入 64 位SHARED_SECRET。第 2 步先部署 Workernpm run deploy⚠️ 顺序别搞反先部署再上传密钥否则线上还没有密钥可供比对。第 3 步上传密钥到 Cloudflarenpx workers-mcp secret upload底层执行wrangler secret put SHARED_SECRET密钥以加密形式存入 Cloudflare之后每次部署都不必重新提交。完整流程说明见 src/scripts/help.ts 和 README.md。 本地开发同样安全.dev.vars 机制开发调试时本地代理src/scripts/local-proxy.ts启动前会检查.dev.vars是否存在且包含SHARED_SECRET缺失则直接报错退出——而不是悄悄降级成无鉴权模式。这意味着本地和线上的密钥是同一份本地调通即线上可用.dev.vars只用于本地生产密钥只存在于 Cloudflare 侧不会随代码仓库泄露启动失败时的报错信息会明确告诉你缺什么排查不迷路。✅ 安全防护检查清单照着过一遍#检查项说明1密钥长度为 64 位过短的密钥会被 Proxy 直接拒绝属于双重保险2.dev.vars未提交到代码仓库本地密钥不应进入版本历史建议加入.gitignore3线上密钥通过wrangler secret put上传密钥以加密形式存储在 Cloudflare不进源码4密钥泄露后立即轮换重新secret generate→npm run deploy→secret upload三步换锁5只在 HTTPS 下调用 Worker密钥走 Bearer 头传输必须加密信道防止中间人嗅探6定期核对.dev.vars与线上密钥一致不一致时所有调用都会收到 401可用secret upload快速修复7部署新 Worker 版本时确认密钥仍有效wrangler types可重新生成类型定义顺带验证配置 写在最后workers-mcp 把和 AI 客户端互通变成了搭积木但它没有为了省事而牺牲安全64 位加密随机密钥 入口硬校验 默认拒绝这套组合让一个公网 Worker 也能放心地接上 Claude Desktop 的工具链。下次部署前花一分钟过一遍上面的检查清单让你的 Worker 体体面面而不是光着膀子跑在公网上 【免费下载链接】workers-mcpTalk to a Cloudflare Worker from Claude Desktop!项目地址: https://gitcode.com/gh_mirrors/wo/workers-mcp创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考