An MCP (Model Context Protocol) server developer is building a filesystem tool server. They notice that Claude, when acting as an MCP client, occasionally calls the write_file tool with a path like ../../etc/passwd — a path traversal attempt that would write outside the intended sandbox directory. The MCP server naively trusts the path provided by Claude. What is the correct security control in the MCP server implementation?
Select an answer to reveal the explanation.
Short Explanation and Infographic
Here's the deal — path traversal attacks can use many obfuscated forms: ../, %2e%2e/, symlinks, null bytes, and other encodings. Simple string filtering (Option A) is bypassable by encoding variations.
Full explanation below image
Full Explanation
Path traversal attacks can use many obfuscated forms: ../, %2e%2e/, symlinks, null bytes, and other encodings. Simple string filtering (Option A) is bypassable by encoding variations. The correct defense is to canonicalize the path to its absolute real form (resolving .., symlinks, and encodings) using the OS's own path resolution, then check that the resolved path is within the permitted base directory. This is defense-in-depth that works regardless of how the traversal is encoded. In MCP architecture, the server must treat all tool inputs as potentially adversarial — whether from direct injection or model errors. Option A fails because ....// or URL encoding bypasses ../ string matching. Option C (API key validation) verifies the caller is Claude, not that Claude's inputs are safe — Claude itself may have received injected content from an external source. Option D (prompt instructions) is not a security control; it can be overridden by prompt injection or model behavior variability.