Local MCP over HTTP: Origin Validation Is the DNS Rebinding Boundary
A local MCP HTTP server can be reached by browser code through DNS rebinding. Binding to loopback, validating each incoming Origin, and authenticating requests are separate adoption requirements.
Read in JapaneseA service listening on 127.0.0.1 is not automatically restricted to trusted desktop software. Browser JavaScript can send requests to network destinations, and DNS rebinding can make an attacker-controlled hostname resolve to a loopback or private address after a page has loaded. If a local Streamable HTTP MCP server accepts that request, a remote website may reach tools that the operator thought were local-only.
The current MCP Streamable HTTP specification, version 2026-07-28, sets three distinct expectations: validate the Origin header on incoming connections, return HTTP 403 when a present Origin is invalid, bind local deployments to 127.0.0.1 rather than 0.0.0.0, and use proper authentication. The same protections appear in the final 2025-11-25 transport, so this boundary applies to both common transport generations.
Three controls answer three different questions
| Control | Question answered | What it does not prove |
|---|---|---|
| Loopback bind | Which network interfaces accept traffic? | Which browser origin initiated a loopback request |
| Origin validation | Is this web origin allowed to call the endpoint? | Who the user is or what the caller may do |
| Authentication and authorization | Which principal and scopes may invoke a tool? | That the endpoint is unreachable from other interfaces |
An adoption review should record the actual listening address from the running process or container, not only a framework default. Container port publishing and reverse proxies can turn an internal bind into a LAN-accessible endpoint. When a proxy terminates HTTP, confirm that Origin reaches the MCP application unchanged and that validation occurs before JSON-RPC parsing or tool dispatch.
Use an exact allowlist of complete origins: scheme, hostname, and port. A suffix check such as “ends with example.com,” a wildcard, or reflecting the supplied Origin defeats the boundary. Decide explicitly how requests with no Origin are handled. Native MCP clients often omit it, while browsers normally include it; an absent header can be allowed for a documented native-client path, but must not bypass authentication.
Host and Origin are not interchangeable. Host identifies the HTTP destination selected by the client; Origin identifies the web security context that initiated a browser request. Validating Host can complement routing controls, but it does not satisfy the protocol requirement to validate Origin. Likewise, setting Access-Control-Allow-Origin only affects whether browser code may read a response. A state-changing request may already have reached the server, so the server must reject an invalid incoming Origin.
A bounded acceptance test
From the supported native client, verify that valid tool traffic succeeds with its expected authentication. From a browser test page on an unapproved origin, send both a simple request and one that triggers preflight; each must fail before tool execution. Repeat through every production ingress path and with a deliberately mismatched Host. Confirm the service is not listening on LAN or wildcard interfaces unless remote access is an intentional, authenticated deployment.
The official versioning page marks 2026-07-28 as Current and /draft as not ready for consumption. Draft behavior may evolve, so deployment acceptance should be tied to the negotiated protocol version and the transport implementation that actually runs.
Scope and limits
Origin validation primarily protects browser-mediated access and DNS rebinding. It does not stop malware or another local process from making direct requests, and it does not sandbox a local MCP process from the filesystem or operating-system credentials. Loopback, Origin, authentication, least-privilege execution, and tool-level authorization remain separate controls.