mcp-server-hardening

Harden an MCP Server

A stdio server needs none of this. An HTTP server needs all of it before it is reachable, because an MCP server is an execution surface that an LLM drives.

Validate Host Names

ASP.NET Core's Kestrel does not check the Host header by default, and it is not alone. Without validation, a browser can be steered to your local server through an attacker-controlled DNS name while sending that name in the header — DNS rebinding.

• Locally: restrict allowed hosts to loopback values.
• In production: configure the exact public host names, and validate at the proxy or load balancer when one forwards requests.

This also stops untrusted host names being reflected through features that generate absolute URLs.

Do Not Enable CORS By Default

Turn on cross-origin requests only if you intend browser-based cross-origin access. When you do, use the most restrictive policy that works.

CORS is not a substitute for host-name validation. They defend different things: CORS governs which browser origins may call you, host validation governs which names you will answer to.

Authenticate

A remote server is a reachable execution surface. Decide who may call it before deploying, not after.

For stdio servers the question does not arise — the transport is the boundary. The mistake is carrying a stdio design onto HTTP and assuming the boundary came along.

Handle Secrets

Read credentials from the environment, never from a file in the repository:

{
  "env": { "MY_API_TOKEN": "${env:MY_API_TOKEN}" }
}

Two failure modes worth naming:

Logging the token. Debug output that dumps request headers will write the credential to a log the user did not know existed. Redact at the logger, not at the call site, because the call site you forget is the one that leaks.

Returning the token. An error message that echoes the full request back to the agent puts the credential into the model's context, and from there into wherever that conversation is stored.