Mcp-Implementation-Security-Review

# MCP Implementation Security Review

Process

Step 1 — Classify the target

- 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.

- 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 `