SSRF and local MCP servers: network risks and defense against DNS rebinding

Introduction

SSRF describes the risk of a service making network requests to unintended destinations under the influence of an input. In an MCP integration, that risk may sit in a tool that fetches URLs, imports files or accesses internal services; it is not inherent to the protocol.

The case of the local service

The Streamable HTTP specification includes a specific warning about DNS rebinding: servers MUST validate the Origin header on every incoming connection and respond with 403 Forbidden if it is present and invalid. For local execution, it states that servers SHOULD bind only to localhost (127.0.0.1) rather than all interfaces (0.0.0.0) and SHOULD implement proper authentication.

Origin validation should not be mistaken for a complete defense for every outgoing request. If a tool accepts URLs or host names, validate the destination against an explicit policy, limit protocols and block internal networks or unnecessary destinations. Revalidate after resolving names and protect against changes between resolution and connection. Do not rely only on domain lists if the tool can redirect or resolve in other ways.

Defense in layers

Reduce the process’s network capabilities through isolation, egress rules and explicit access to required destinations. Disable automatic redirects or revalidate every redirected destination. Set limits on time, size and number of requests. Record the logical destination and the policy decision for auditing, avoiding storing sensitive response data.

Test these controls in a controlled environment, including private addresses and resolution changes. Do not use real MCP services or third-party networks as test targets.

Conclusion

For local servers, combine validated Origin, binding to localhost and authentication; for outgoing requests, add a destination policy and network controls. A single check does not cover both directions.