Repository navigation
MCP: Reject requests from unapproved browser origins #2630
Description
Ensure that deployed MCP endpoints reject requests from unapproved browser origins. An origin identifies the website making the request. Localhost checks alone do not establish the policy for the public service. This is required for the launch in #2408.
Inspect the application and public edge first, then reuse an effective existing control where possible. Support the agreed native-client behavior when no Origin header is present. Approved browser clients also need to read the OAuth challenge and reach resource metadata.
This ticket is done when tests cover approved, rejected, malformed, and absent origins, plus any required browser preflight requests. Record where the check runs and verify it through the public deployment in #2634.
Status on October 23, 2026
Draft PR #2657 adds the application side. The MCP endpoint now rejects any request whose Origin is not on the new stargate.jsonapi.mcp.allowed-origins list, which is empty by default. Requests without an Origin header still pass, and an approved browser gets a CORS preflight answer without sending credentials. The approved origins still need agreement with #2642, and public-edge verification remains in #2634.
Implementation requirements and source references
Tracking issue: #2408.
Tracking correspondence: m4 and L2/L4 browser transport verification. Required for launch. Shared requirement IDs remain stable across the delivery plan and #2408.
Why
The MCP HTTP protocol requires servers to reject invalid browser Origins. Quarkiverse 2.0.3's built-in check protects localhost bindings. That alone does not establish the policy for Data API behind its deployed edge.
The repository has no explicit deployed MCP Origin policy, and the edge configuration has not been checked. This is a deployment requirement to verify for the upgrade, not evidence of a confirmed production exposure.
Work
- Inspect application and edge configuration against the client/Origin policy from MCP: Agree the supported protocol and authentication policy #2624.
- Reuse an existing effective check if present. Otherwise, add exact Origin validation at MCP entry points, with legacy routes removed or blocked under MCP: Agree the supported protocol and authentication policy #2624.
- Reject malformed or unapproved Origins before tools execute. Preserve the agreed behavior for native clients without an Origin header.
- If browser clients are supported, configure their approved CORS preflight requests for Authorization, MCP-Protocol-Version, Mcp-Method and Mcp-Name. Expose the WWW-Authenticate challenge to approved browser clients and verify protected-resource metadata reachability. Do not use permissive CORS as a substitute for token validation.
Done when
Tests cover non-local deployment, approved/rejected/absent Origins, deceptive matches, and any required preflight flow. Record where validation is enforced and verify it through the edge in #2634.
Depends on #2624. Reuse relevant tests from #2591. See the HTTP requirements.
Modern protocol and OAuth acceptance details
Match Origins exactly by the reviewed policy, including scheme/host/port. Test deceptive suffixes, malformed and unapproved values, absent Origin for native clients, and permitted preflight headers. Reuse an effective edge control when present. Verify the actual public endpoint, not only localhost. OAuth validates identity and permission independently of Origin.
Changelog traceability
- m4 Validate standard HTTP headers, lines 35 — Required.
Normative detail: Streamable HTTP, authorization, caching.
Activity
[-]Validate Origins on MCP HTTP endpoints[/-][+]MCP: Validate Origins on HTTP endpoints[/+][-]MCP: Validate Origins on HTTP endpoints[/-][+]MCP: Validate Origins on deployed HTTP endpoints[/+][-]MCP: Validate Origins on deployed HTTP endpoints[/-][+]MCP: Reject requests from unapproved browser origins[/+]