The current DnsRebindingProtectionMiddleware handles Host and Origin as alternatives:
- If an
Origin header is present, only its hostname is checked.
- Otherwise, the
Host header is checked.
- Both values are checked against the same
allowedHosts list.
This causes several issues:
- An invalid
Host header is not rejected when an allowed Origin header is present.
Host and Origin represent different parties: Host identifies the target MCP server, while Origin identifies the web origin initiating the request. They commonly have different values and therefore require separate allowlists.
- Origin validation is reduced to the hostname. This makes it impossible to distinguish origins by scheme or port, even though those are part of the web-origin tuple.
Would it make sense to either:
- Split this into separate Host and Origin validation middleware; or
- Extend
DnsRebindingProtectionMiddleware with separate allowedHosts and allowedOrigins options, validating Host on every request and additionally validating Origin whenever it is present?
I would be happy to submit a pull request if this direction is acceptable.
The current
DnsRebindingProtectionMiddlewarehandlesHostandOriginas alternatives:Originheader is present, only its hostname is checked.Hostheader is checked.allowedHostslist.This causes several issues:
Hostheader is not rejected when an allowedOriginheader is present.HostandOriginrepresent different parties:Hostidentifies the target MCP server, whileOriginidentifies the web origin initiating the request. They commonly have different values and therefore require separate allowlists.Would it make sense to either:
DnsRebindingProtectionMiddlewarewith separateallowedHostsandallowedOriginsoptions, validatingHoston every request and additionally validatingOriginwhenever it is present?I would be happy to submit a pull request if this direction is acceptable.