Security Best Practices changeddocs/draft/tutorials/security/security_best_practices
Upstream edited this page at 28 Jul 2026 15:42 UTC, give or take a minute or two: the time comes from Anthropic’s own sitemap rather than from a commit. This site recorded the change at 22 Oct 2026 20:37 UTC.
Upstream edited
Recorded here
Lines+13added
Lines−13removed
From line
8
where the diff opens
First seen
26 Aug 2026
this site's first read of the page
Recorded edits3to this page, all time
The whole hunk
from line 8, old and new numbered
/
from line 8
88
99This document provides security considerations for the Model Context
1010Protocol (MCP), complementing the
11[MCP Authorization](/specification/latest/basic/authorization)
11[MCP Authorization](/specification/latest/basic/authorization.md)
1212specification. This document identifies security risks, attack vectors,
1313and best practices specific to MCP implementations.
1414
from line 148
148148 consent screen
1491496. The MCP authorization code is redirected to the attacker's server
150150 (specified in the malicious `redirect_uri` parameter during
151 [dynamic client registration](/specification/latest/basic/authorization#dynamic-client-registration))
151 [dynamic client registration](/specification/latest/basic/authorization.md#dynamic-client-registration))
1521527. The attacker exchanges the stolen authorization code for access
153153 tokens for the MCP server without the user's explicit approval
1541548. The attacker now has access to the third-party API as the compromised
from line 303
303303#### Risks
304304
305305Token passthrough is explicitly forbidden in the
306[authorization specification](/specification/latest/basic/authorization)
306[authorization specification](/specification/latest/basic/authorization.md)
307307as it introduces a number of security risks, that include:
308308
309309* **Security Control Circumvention**
from line 484
484484
485485SSRF risks are not limited to MCP clients. When an authorization
486486server supports
487[Client ID Metadata Documents](/specification/draft/basic/authorization/client-registration#client-id-metadata-documents),
487[Client ID Metadata Documents](/specification/draft/basic/authorization/client-registration.md#client-id-metadata-documents),
488488the authorization server takes a URL as input from an unknown client
489489and fetches that URL. A malicious client could use this to trigger
490490the authorization server to make requests to arbitrary URLs, such as
from line 514
514514
515515### State Handle Hijacking
516516
517MCP is [stateless](/specification/draft/basic/index#statelessness) and
517MCP is [stateless](/specification/draft/basic/index.md#statelessness) and
518518has no protocol-level sessions. Servers that need state spanning
519519multiple requests mint an explicit handle, such as a shopping cart ID
520520or a workflow ID, and receive it back as an ordinary tool argument on
from line 553
553553
554554For guidance on securing the server-assigned session IDs used by
555555protocol version `2025-11-25` and earlier, see
556[Session Hijacking in the 2025-11-25 version of this page](/docs/2025-11-25/tutorials/security/security_best_practices#session-hijacking).
556[Session Hijacking in the 2025-11-25 version of this page](/docs/2025-11-25/tutorials/security/security_best_practices.md#session-hijacking).
557557
558558### Local MCP Server Compromise
559559
from line 806
806806
807807#### Mitigation
808808
809[Authorization Response Validation](/specification/draft/basic/authorization#authorization-response-validation)
809[Authorization Response Validation](/specification/draft/basic/authorization.md#authorization-response-validation)
810810mitigates this by binding the response to the authorization server
811811the client recorded before redirecting, so the authorization code
812812cannot be redeemed at an unintended token endpoint. PKCE alone does
from line 821
821821
822822Native and locally-running MCP clients commonly use `localhost`
823823redirect URIs. When clients identify themselves with
824[Client ID Metadata Documents](/specification/draft/basic/authorization/client-registration#client-id-metadata-documents),
824[Client ID Metadata Documents](/specification/draft/basic/authorization/client-registration.md#client-id-metadata-documents),
825825the metadata document proves control of a domain, but it cannot prove
826826which local process is listening on a `localhost` redirect URI.
827827
from line 842
842842#### Mitigation
843843
844844See
845[Localhost Redirect URI Risks](/specification/draft/basic/authorization/security-considerations#localhost-redirect-uri-risks)
845[Localhost Redirect URI Risks](/specification/draft/basic/authorization/security-considerations.md#localhost-redirect-uri-risks)
846846in the authorization specification for the countermeasures expected
847847of authorization servers, including displaying additional warnings for
848848`localhost`-only redirect URIs and clearly displaying the redirect URI
from line 851
851851### CIMD Trust Policies
852852
853853Authorization servers that accept
854[Client ID Metadata Documents](/specification/draft/basic/authorization/client-registration#client-id-metadata-documents)
854[Client ID Metadata Documents](/specification/draft/basic/authorization/client-registration.md#client-id-metadata-documents)
855855can apply domain-based trust policies to decide which URL-based
856856client IDs to accept:
857857
from line 863
863863 to prevent phishing
864864
865865Servers maintain full control over their access policies. See
866[Trust Policies](/specification/draft/basic/authorization/security-considerations#trust-policies)
866[Trust Policies](/specification/draft/basic/authorization/security-considerations.md#trust-policies)
867867in the authorization specification, along with
868868[Section 6.4](https://www.ietf.org/archive/id/draft-ietf-oauth-client-id-metadata-document-00.html#section-6.4)
869869and
from line 936
936936
937937When the initial `WWW-Authenticate` challenge carries no `scope`
938938parameter, the
939[Scope Selection Strategy](/specification/draft/basic/authorization#scope-selection-strategy)
939[Scope Selection Strategy](/specification/draft/basic/authorization.md#scope-selection-strategy)
940940directs clients to fall back to requesting all scopes listed in
941941`scopes_supported`. This approach accommodates the general-purpose
942942nature of MCP clients, which typically lack domain-specific knowledge
from line 952
952952> **SHOULD** compute the union of previously requested scopes and newly
953953> challenged scopes when initiating re-authorization, as described in [Step-Up
954954> Authorization
955> Flow](/specification/draft/basic/authorization#step-up-authorization-flow).
955> Flow](/specification/draft/basic/authorization.md#step-up-authorization-flow).
956956> This allows servers to remain stateless with respect to client scope sets
957957> while ensuring clients do not lose previously granted permissions.
958958
No line in this hunk matches that.