A reviewer accepts a locally-run HTTP MCP server that validates Origin strictly but binds to every interface, arguing that the validation makes the binding harmless. Assess that reasoning.

The principle — Two controls listed together are usually covering two different holes, and a review that treats them as redundant needs to say which caller each one stops.

Why the key is correct — The specification asks for both, separately. Servers MUST validate the Origin header on all incoming connections to prevent DNS rebinding attacks. And, as a distinct item, when running locally, servers SHOULD bind only to localhost (127.0.0.1) rather than all network interfaces (0.0.0.0). They protect against different callers. Origin validation defends against a browser page that has been steered at the loopback address, because a browser attaches an origin to what it sends. Binding narrowly defends against everything else on the network, which has no browser attaching anything and can simply omit the header or forge it. The consequence the pair is written against is stated plainly: without these protections, attackers could use DNS rebinding to interact with local MCP servers from remote websites — and the plural is doing work in that sentence.

Why the others are wrong — The measures are not two spellings of one control. The browser's own protections are what rebinding is designed to evade, which is why the requirement sits on the server. And the Origin check here is a security requirement, not routing hygiene.

Remember this — Origin validation is for the browser; narrow binding is for everything else. Neither excuses the other, and a review that accepts one in place of the other has quietly narrowed the threat model to whichever caller it happened to think of first.

Sources — MCP first-party documentation.