MCP Implementation Security 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):

Local-only (best practices only):

Host binding gotchas:

…