MCP Security Best Practices From the Spec

The MCP specification includes an official Security Best Practices page. It lists the main attacks on MCP implementations and the countermeasures expected of clients, servers and authorization servers. For the 2026-07-28 version, the latest as of October 2026, it covers 11 attack areas.

The page says it "complements" the MCP Authorization specification. Its audience is "developers implementing MCP authorization flows, MCP server operators, and security professionals." Business readers can still use it as a checklist for vendors and developers.

This guide summarizes each section in plain English, with the key MUST rules. It also pulls in the security rules from the core spec, tools and transport pages. Everything was checked against the spec on 28 October 2026.

The 11 sections at a glance

What each section means

Confused deputy problem

This applies to an MCP server that acts as a proxy to a third-party API using one static client ID. A consent cookie from a past login can let an attacker skip the consent screen and receive a code. Proxy servers MUST store consent per client, show a consent page naming the client and scopes, validate redirect URIs exactly, and handle state safely. Read more in the confused deputy problem in MCP.

Token passthrough

The page calls this an "anti-pattern." A server accepts a client's token and forwards it downstream without checking it was issued for the server. The mitigation is one line: servers "MUST NOT accept any tokens that were not explicitly issued for the MCP server." See why MCP servers must not pass tokens through.

Server-side request forgery

A malicious server can plant internal URLs in OAuth metadata. The page lists private IP ranges to block, warns against hand-written IP parsers, and suggests egress proxies. Our SSRF guide covers it in depth.

State handle hijacking

This section reflects the 2026-07-28 move to statelessness. MCP now has "no protocol-level sessions." Servers that need state return a handle, such as a cart ID. The page says servers MUST verify all inbound requests and SHOULD bind handles to the authenticated user. Guidance for older session IDs now lives in the 2025-11-25 version of the page.

Local MCP server compromise

Local servers run on the user's machine. The page lists three attack paths: a malicious startup command, a malicious package, and DNS rebinding. Clients offering one-click setup MUST show the full command "without truncation" and require approval. They SHOULD sandbox servers. Local servers SHOULD use stdio, or require a token if they use HTTP.

OAuth authorization URL validation

A malicious server can supply a javascript: URL or a URL with shell commands in it. Clients MUST reject dangerous schemes and MUST NOT open URLs with cmd.exe, sh or PowerShell. Web clients SHOULD use a Content Security Policy.

stdio transport in proxy scenarios

The page says stdio "is not inherently vulnerable." The risk is a local proxy that spawns servers as child processes. If an attacker steals the proxy's token through XSS, they can make it run commands. Proxies SHOULD sandbox spawned processes and log stdio use.

Mix-up attacks

An attacker who controls one authorization server tries to get a code meant for another. The fix is the iss check defined in the authorization spec. The page notes "PKCE alone does not prevent this attack."

Localhost redirect URI impersonation

Client ID Metadata Documents prove a domain, but not which local process listens on a localhost redirect. Authorization servers should warn on localhost-only redirect URIs and clearly display the redirect hostname.

CIMD trust policies

Authorization servers that accept Client ID Metadata Documents can choose who to trust: allowlists, any HTTPS client ID, reputation checks, or domain age rules.

Scope minimization

Broad scopes make a stolen token far more damaging. The page recommends a minimal starting scope, step-up with targeted challenges, and logging of elevation events. It lists common mistakes, including "wildcard or omnibus scopes."

Security rules elsewhere in the spec

The best practices page is not the only place with security rules.

• Core principles. The specification overview says users must consent to data access, hosts must not send resource data elsewhere without consent, and "tools represent arbitrary code execution."
• Tools. The tools page says servers MUST validate inputs, control access, rate limit, and sanitize outputs. Clients SHOULD confirm sensitive operations, show inputs, set timeouts and log usage.
• Transport. The Streamable HTTP page says servers MUST validate Origin and return 403 when invalid.
• Authorization. The security considerations page covers token storage, PKCE, HTTPS and open redirection.
• Elicitation. The elicitation page bans asking for passwords or API keys in form mode.

What the page does not cover

The page is focused on protocol and OAuth attacks. It does not deeply cover prompt injection, tool poisoning or supply chain risks. For those, OWASP's MCP Top 10 is the better reference. See the OWASP MCP Top 10, explained.

The spec also admits its limits. The overview says "MCP itself cannot enforce these security principles at the protocol level." Each client and server has to implement them.

How to use this page

• If you buy MCP servers, ask vendors which sections apply to them and how they meet the MUSTs. Our MCP vendor security questionnaire turns this into questions.
• If you build MCP servers, read the sections for your role before you design auth. Then check your build against them.
• If you run IT, use the local server and scope sections to set policy.

Next step

Turn the spec into a working list for your own setup. Our MCP security checklist covers these rules in copy-and-use form, and our MCP readiness audit checks your servers against them.

Frequently asked questions