security: enforce MCP Origin allowlist to prevent DNS-rebinding attacks

[prakhar-singh1928]

Summary

Implements the MCP 2026-07-28 Streamable HTTP
Origin validation requirement
to prevent DNS-rebinding attacks on the gateway MCP endpoint.

Closes #421.

Changes

• mcp_origin_layer — outermost middleware in layers/mcp_origin.rs.
  Validates Origin before JWT auth, session creation, or any backend call.
  Returns HTTP 403 for non-allowlisted, malformed, or null Origins.
  Missing Origin is always accepted (native MCP clients).

• Strict serialized-origin validation — pre-parse checks reject backslash,
  userinfo (@), query, and fragment before the url crate ever sees the
  value, preventing WHATWG normalization from silently repairing malformed input.
  Post-parse checks confirm no userinfo/path/query/fragment survived.
  Uses typed url::Origin (not Url) for equality comparison.

• Empty allowlist rejects every present Origin — there is no same-origin
  fallback. A DNS-rebinding attacker can control both Host and Origin
  simultaneously; comparing them provides no protection.

• Host check uses http::uri::Authority — the Host header is parsed as
  a bare authority (no scheme inference). Origin validation uses the allowlist
  only; it never synthesizes a URL from Host.

• Config.mcp_allowed_origins — allowlist wired to
  --mcp-allowed-origins / CONTEXTFORGE_GATEWAY_RS_MCP_ALLOWED_ORIGINS.
  Parsed once at startup via Config::finalize(); pre-parsed Vec<url::Origin>
  stored in Config.mcp_parsed_origins for zero-cost per-request lookup.

• Config.mcp_allowed_hosts — companion Host allowlist wired to
  --mcp-allowed-hosts / CONTEXTFORGE_GATEWAY_RS_MCP_ALLOWED_HOSTS.

• RMCP disabled — StreamableHttpServerConfig uses
  disable_allowed_origins() unconditionally; mcp_origin_layer is the
  sole enforcement point.

• docs/book/src/security-model.md — updated MCP Origin and Host
  Validation section citing 2026-07-28; empty-allowlist behavior documented.

• docs/book/src/request-flow.md — mcp_origin_layer added to the
  HTTP middleware stack order.

Testing

78 unit and router integration tests including:

• Missing Origin always accepted
• Empty allowlist rejects any present Origin (DNS-rebinding regression)
• Attacker-controlled matching Host+Origin rejected without explicit allowlist
• HTTPS allowlisted origin on origin-form request (no scheme in URI)
• HTTP origin rejected when only HTTPS is allowlisted
• Backslash origin rejected (pre-parse, before url normalization)
• Userinfo origin rejected
• Query/fragment origin rejected
• Default-port normalization in both directions (:443 ↔ portless)
• Non-default port :8443 vs portless (distinct origins)
• null, malformed, GET/POST/DELETE methods, 403 body content
• Host allowlist: exact match, port-wildcard, port-specific, mismatch

[lucarlig]

Thanks for adding early Origin enforcement and focused coverage. I am requesting changes because the implementation does not yet satisfy the MCP 2026-07-28 Streamable HTTP security requirement.

Blocking issues:

• Origin validation is opt-in and disabled by default, although the specification requires validation on all incoming connections.
• The custom parser reimplements standards-sensitive URL/origin behavior and treats a portless origin as a wildcard for every port. Please use the workspace existing url = 2.5.8 crate and compare typed url::Origin values instead.
• The new CLI/environment flag is unnecessary and creates a supported insecure state for a mandatory transport invariant.

Please remove the optional configuration surface, enforce validation automatically for every request carrying Origin while continuing to allow requests without it, use Url::parse(...).origin() for canonical typed comparison, and add regressions for the empty-policy and non-default-port cases. Update the security and request-flow documentation to cite and describe MCP 2026-07-28.

The early middleware ordering and HTTP 403 behavior are directionally correct. This review is limited to the Origin-validation scope; the broader stateless MCP migration remains separate.

[dawid-nowak]

See comments, but generally speaking ideally we should be re-using the Rust crates as much as possible especially the ones that are widely used and trusted.

In this is case, a lot of code can be simplified/removed if url::Url is used.

[prakhar-singh1928]

@lucarlig

[P1] Keep Origin validation active when the allowlist is empty

Fixed. The early-return bypass is gone. When mcp_allowed_origins is empty (the default), validation does not disable — it falls back to a same-origin check: the Origin header value must equal the derived Host URL. A present Origin that doesn't match the host, is null, or is malformed still returns HTTP 403. Only a missing Origin is unconditionally accepted (native/non-browser clients).

[P1] Replace the custom Origin parser with the url crate

Fixed. The hand-rolled NormalizedOrigin struct and its scheme/host/port splitter are gone. Both sides of every comparison go through url::Url::parse, and equality is Url == Url directly. The crate handles default-port elision, IDNA, and case-folding. url is now a shared [workspace.dependencies] entry (required by cargo-deny's workspace-duplicate rule, which also caught the previous breakage).

[P1] Do not expose mandatory validation as a new CLI opt-out

Fixed. There is no disable flag. The two new fields — CONTEXTFORGE_GATEWAY_RS_MCP_ALLOWED_ORIGINS and CONTEXTFORGE_GATEWAY_RS_MCP_ALLOWED_HOSTS — are allowlists only. Leaving them empty does not disable protection; it activates the same-origin fallback described above.

[P2] Document MCP 2026-07-28, remove weakened SHOULD language

Fixed. docs/book/src/security-model.md now cites 2026-07-28, carries a decision table for both the non-empty and empty-allowlist cases, and uses no optional language. docs/book/src/request-flow.md includes mcp_origin_layer in the HTTP stack order and the middleware context table.

---

@dawid-nowak

• origin_to_url() is now a thin wrapper: appends "/" so the parser accepts a bare scheme://host[:port] string, rejects any path beyond the root slash we added, and rejects hostless URLs (e.g. data:, blob:). Everything else is delegated to the url crate.

• the url crate handles this automatically: it silently strips the default port on parse, so https://blah.com:443 and https://blah.com are the same Url. Non-default ports are preserved and cause inequality. Four regressions confirm both directions:

• https_default_port_443_equals_portless / http_default_port_80_equals_portless

• non_default_port_8443_is_distinct_from_portless

• allowlist_entry_with_443_matches_portless_request

• allowlist_8443_entry_does_not_match_default_port

[lucarlig]

Thanks for the updates. CI is green, but four issues remain:

1. [P1] Default DNS-rebinding protection is ineffective. Origin == Host compares two attacker-controlled values, so a rebinding domain can pass. Remove this fallback: missing Origin may pass, but a present Origin must match an explicit trusted allowlist; an empty allowlist should return 403.

2. [P1] HTTPS is inferred as HTTP. Normal HTTP/1 requests contain /mcp, not a URI scheme, so scheme_str().unwrap_or("http") rejects valid HTTPS origins. Do not synthesize a URL from Host; parse Host as http::uri::Authority, and use only explicitly configured origins for Origin validation.

3. [P2] Malformed Origins are normalized and accepted. url::Url repairs values such as https:\app.example.com and empty userinfo. Strictly validate serialized-origin syntax, reject userinfo/path/query/fragment/backslashes and opaque origins, then compare typed url::Origin values. Parse configured origins once at startup and reject invalid configuration.

4. [P2] The PR description is stale. It still references MCP 2025-11-25, describes validation as opt-in, says Host validation is excluded, and claims RMCP Origin validation is enabled. Update it to match the final 2026-07-28 behavior.

Please add regressions for matching attacker-controlled Host/Origin, HTTPS origin-form requests, and malformed-but-normalizable Origin values. After these changes, this should be ready for another review.

[lucarlig]

Most of the prior feedback is now addressed: an empty allowlist rejects every present Origin, Host is no longer used to synthesize an Origin, HTTPS origin-form requests work, typed url::Origin equality handles default/non-default ports, and the PR description is current.

Three items remain, so I am requesting changes:

1. [P2] Strict serialized-origin validation is incomplete. url::Url still repairs malformed values such as https:////app.example.com, https:///app.example.com, https://app.example.com:, and leading-whitespace values. Each becomes the same typed tuple as https://app.example.com, so a malformed present Origin can be accepted when the canonical origin is allowlisted. Enforce exact scheme://authority syntax before Url::parse and add regressions.

2. [P2] Invalid configured origins do not reject startup configuration. parse_allowed_origins uses filter_map, logs, and silently drops invalid entries. Return a Result from this parser/Config::finalize and propagate the error from run_gateway.

3. [P2] request-flow.md still describes the removed same-origin fallback. The stack summary and middleware table must say that an empty allowlist rejects every present Origin.

Reproduction

Run against commit 44b2d35c1fa04791bcba531c07d81d42fb43bcc6:

cargo test -p contextforge-gateway-rs-lib mcp_origin -- --nocapture
cargo test -p contextforge-gateway-rs-lib invalid_configured_origin_is_skipped -- --nocapture

[lucarlig]

@prakhar-singh1928 Thanks for the latest update. I retested head 50ba8eb77e3c877df9b708bac295c0ccc59a19b3. CI is green, the focused Origin tests pass, and cargo nextest run --locked --workspace passes all 141 tests. The three cases from my last review are addressed, but two P2 items remain.

1. Strict serialized-Origin validation is still incomplete. With https://app.example.com allowlisted, both of these malformed Origin values reach the handler and return HTTP 204 instead of 403:

   • https://app.example.com/.
   • https://app.\texample.com (embedded horizontal tab)

   The first is normalized from a dot-segment path to /; the second has the tab removed by the URL parser. The current url.path() == "/" check runs after this normalization, so it cannot prove that the raw header contained no path. Please reject any raw / after the scheme:// separator and any ASCII whitespace/control characters before calling Url::parse, while retaining typed url::Origin equality for canonical scheme/host/port comparison.

   A focused router regression can cover both:

   #[tokio::test]
   async fn normalized_malformed_origins_return_403() {
       let app = make_app(config_origins(&["https://app.example.com"]));
   
       for origin in ["https://app.example.com/.", "https://app.\texample.com"] {
           let req = Request::builder()
               .uri("/mcp")
               .method("POST")
               .header(header::ORIGIN, origin)
               .body(Body::empty())
               .unwrap();
   
           let res = app.clone().oneshot(req).await.unwrap();
           assert_eq!(res.status(), StatusCode::FORBIDDEN, "{origin}");
       }
   }

2. security-model.md still describes the old startup behavior. Lines 102–103 say invalid configured origins are “logged and skipped,” but Config::finalize() now returns an error and aborts startup. Please update that sentence to match the implementation.

After those changes, this should be ready for another review.

[lucarlig]

LGTM

[dawid-nowak]

I left some comments in-line.
I am not a big fan of long comments which are there to describe to what the code is doing. Most of the times, the comments are longer than the actual code.

So for example, instead of describing that the string contains host: port, why not just using Vec instead of Vec