retoor
251c3dc2ba
- wire spec: lifecycle, stdio + Streamable HTTP transports, tools, utilities, legacy SSE, versioning, changelog (14 Tier 1) - client ecosystem: Claude Code/VS Code/Cursor/Codex configs, mcp-remote, Smithery, registries, Glama (12 Tier 1) - security/ops: authorization draft, trust model, poisoning, rug pulls, production hardening (12 Tier 1) + 68 Tier 2 cards - conclusions: minimal stdlib client on 2025-11-25, normalizer + resolver agent for pasted configs/GitHub URLs, untrusted-until- consent trust model; nothing built yet - audit PASS (14 subjects, 797 sources, 32 conclusions)
57 lines
4.1 KiB
Markdown
57 lines
4.1 KiB
Markdown
# Security Best Practices
|
|
|
|
## Metadata
|
|
|
|
| Field | Value |
|
|
|---|---|
|
|
| Institute | Molodetz Institute - Research & Retrieval Division |
|
|
| Subject | mcp-client-support |
|
|
| Document type | Source Dossier |
|
|
| Tier | 1 |
|
|
| Source title | Security Best Practices |
|
|
| Source URL | https://modelcontextprotocol.io/specification/2025-11-25/basic/security_best_practices |
|
|
| Source publisher / author | MCP specification authors |
|
|
| Source type | standard |
|
|
| Source date (published) | 2025-11-25 (version date; no separate publish date stated) |
|
|
| Date researched | 2026-10-18 |
|
|
| Researched by | tai (agent), model: Claude Sonnet 5, on behalf of retoor |
|
|
| Research method | gather-subagent direct page fetch, parent synthesis from evidence pack |
|
|
| Confidence | High |
|
|
| Status | Active |
|
|
|
|
## Summary
|
|
|
|
The version-dated companion to the spec gives the authoritative client-side control list: per-client consent through a server-owned consent page showing scopes and redirect URI, a ban on token passthrough, client-owned SSRF and authorization-URL validation, one-click local-server spawn consent with sandboxing, and least-privilege scope discipline. It also forbids session-based authentication for servers and requires secure, non-deterministic session IDs.
|
|
|
|
## Key findings
|
|
|
|
- Confused-deputy via proxy: when a proxy uses one static client ID upstream plus DCR downstream plus consent cookies, an attacker can skip consent; mitigation requires "per-client consent" with an "MCP server-owned consent page" that MUST "Display the specific third-party API scopes" and "Show the registered `redirect_uri`", with consent "Bind to the specific `client_id`".
|
|
- "Token passthrough is explicitly forbidden": "MCP servers **MUST NOT** accept any tokens that were not explicitly issued for the MCP server."
|
|
- SSRF is a client duty: "MCP clients deployed to a server **MUST** consider SSRF risks" when fetching `resource_metadata`, `authorization_servers`, and token/authorization endpoints; SHOULD enforce HTTPS, block private ranges (`10/8`, `172.16/12`, `192.168/16`, `169.254/16` including cloud metadata), validate redirect targets, and consider egress proxies.
|
|
- Authorization-URL validation: clients "MUST only allow `http://` and `https://` schemes", "MUST reject `javascript:`, `data:`, `file:`, `vbscript:`", and "MUST NOT use shell commands... to open URLs".
|
|
- Local-server consent: "If an MCP client supports one-click local MCP server configuration, it **MUST** implement proper consent mechanisms": "Show the exact command... without truncation", flag `sudo`/`rm -rf`/network operations, "Warn that MCP servers run with the same privileges as the client", and sandbox with minimal privileges.
|
|
- Scope minimization: "Minimal initial scope set... Incremental elevation via targeted `WWW-Authenticate` `scope` challenges"; common mistakes include "Using wildcard or omnibus scopes (`*`, `all`, `full-access`)" and "Treating claimed scopes in token as sufficient without server-side authorization logic".
|
|
- "MCP Servers **MUST NOT** use sessions for authentication" and "MUST use secure, non-deterministic session IDs".
|
|
|
|
## Pros / strengths
|
|
|
|
- Most actionable spec-adjacent source: concrete UX content rules, exact blocked IP ranges and URL schemes, exact spawn-consent content.
|
|
- Correctly assigns SSRF and spawn consent to the client, closing the "somebody else's problem" gap.
|
|
- The wildcard-scope anti-pattern list gives scope design a reviewable checklist.
|
|
|
|
## Cons / limitations / caveats
|
|
|
|
- Companion guidance, not the normative spec itself; version-dated 2025-11-25 with no separate publish date, so its standing relative to draft revisions needs tracking.
|
|
- Server-directed rules (no token passthrough, no session auth) are things the client cannot verify, only assume.
|
|
- Sandboxing is required in principle ("minimal privileges") but no mechanism or platform guidance is given.
|
|
|
|
## Relevance to tai
|
|
|
|
The authoritative client-side control list for tai: consent UX content rules, SSRF/URL validation, stdio spawn consent plus sandboxing, least-privilege scopes.
|
|
|
|
## Changelog
|
|
|
|
| Date | Change |
|
|
|---|---|
|
|
| 2026-10-18 | Initial dossier created. |
|