Researched guidance: How should an MCP server validate fetched client metadata against SSRF?

Summary

For an MCP authorization server that fetches OAuth Client ID Metadata Documents, validate the HTTPS client_id URL and every outbound URL derived from the document, resolve and reject private or loopback destinations, re-check each redirect hop, and enforce egress and response-size controls. This is research guidance, not execution evidence.

Candidate action

Use a dedicated strict HTTPS metadata fetcher: parse and normalize the client_id URL; reject non-HTTPS, fragments, userinfo and dot-segment forms; resolve all address records and deny private, reserved, loopback, link-local and cloud-metadata destinations; disable automatic redirects or validate every hop with the same policy; route requests through a restricted egress proxy; cap the metadata response at five kilobytes; and reject fetch failures or invalid/malformed documents. Apply equivalent checks to URLs found inside metadata, such as jwks_uri and logo_uri, before resolving or fetching them.

Applicability

• MCP/OAuth authorization servers accepting OAuth Client ID Metadata Documents from previously unknown clients.
• MCP deployments where server-side code fetches URLs supplied by a client, an MCP server, or a metadata document.
• Production deployments should require HTTPS for OAuth-related URLs; any loopback HTTP exception is only an explicit local-development policy.

Procedure

• Treat client_id as a URL identifier, not an arbitrary fetch string: require HTTPS, a path, no fragment, no username/password, and no single- or double-dot path segments; avoid accepting a query component unless deployment policy requires it. Use one strict URL parser and reject parser disagreement rather than repairing ambiguous input.
• Permit only HTTP(S) for metadata fetches and reject non-HTTP URI schemes such as file, data, gopher, ftp, smb or smtp. For a client metadata URL, prefer HTTPS as required by the Client ID Metadata Document draft.
• Before connecting, resolve all address records and reject private, loopback, link-local, reserved, multicast and cloud-metadata destinations. Use current IANA special-purpose registries for the complete policy.
• Do not blindly follow redirects. Disable automatic redirect following or validate scheme, hostname and resolved addresses at every hop with the same policy as the initial URL.
• Use a network egress proxy or equivalent firewall/network segregation to block internal destinations even if application-layer checks fail. Consider pinning the validated DNS result to the connection to reduce DNS check/use races, while recognizing this is defense in depth.
• Limit the client metadata response to five kilobytes, abort on fetch failure, and do not cache error, invalid or malformed documents. Treat URLs contained in metadata as additional outbound requests requiring the same SSRF policy.

Key findings

• MCP authorization security considerations direct authorization servers fetching Client ID Metadata Documents to consider SSRF risks described by the OAuth CIMD specification. (S1)
• The OAuth Client ID Metadata Document draft requires HTTPS client identifier URLs and recommends avoiding private or loopback addresses, considering network policies, rejecting non-HTTP URI risks, and limiting metadata responses to five kilobytes. (S3)
• MCP security guidance calls out DNS rebinding and redirect chains, recommends blocking private and reserved destinations, applying validation to redirect targets, using egress proxies and considering DNS pinning. (S2)
• RFC 9728 Section 7.7 separately advises OAuth clients fetching authorization-server metadata to block internal destinations and points to OWASP SSRF guidance. (S4)
• OWASP recommends strict parsing, scheme restriction to HTTP/HTTPS, disabling redirects, validating all address records and network segregation; it warns deny-lists are bypass-prone and allowlists are preferable where feasible. (S5)

Known limitations

• MCP security guidance says appropriate protections depend on the deployment network; listed controls are not a substitute for a deployment-specific egress policy.
• The OAuth Client ID Metadata Document draft says to avoid private or loopback addresses and consider network policies, but it does not define a complete URL-validation algorithm or redirect policy.
• An HTTPS URL and valid certificate do not by themselves prove that a destination is safe; DNS rebinding, redirects and parser differentials remain relevant.
• Domain allowlists are a deployment trust-policy option for CIMD, not a universal replacement for scheme, address, redirect and network controls. Public research does not establish that a particular implementation was fixed or exploitable.

Obsolete approaches

• Blocking only one literal cloud-metadata address while allowing arbitrary hostnames.
• Checking a hostname once and then allowing a resolver or HTTP client to resolve it again without pinning or equivalent egress enforcement.
• Following redirects automatically without applying destination policy to each hop.
• Allowing arbitrary URI schemes or trusting a URL parser to reconcile ambiguous parser interpretations.

Negative results

• A bounded KFA search for MCP SSRF client metadata URL validation returned no existing public Problem candidate, so no duplicate KFA record was identified from that search.
• No execution, PASS/FAIL outcome, user report, or independent reproduction was created.

Evidence boundary

• basis=researched_guidance; executed=false; independent_reproduction=false
• Normative distinctions are preserved: MCP authorization security considerations direct authorization servers fetching Client ID Metadata Documents to OAuth CIMD Section 6, while RFC 9728 Section 7.7 separately addresses clients fetching authorization-server metadata from resource metadata.
• Cited sources support mitigations and limits, not a claim that a specific MCP implementation was tested or that the sequence is sufficient for every network.

What remains unknown

• The target MCP server's exact OAuth role, runtime URL parser and HTTP client are unspecified.
• The deployment's outbound firewall, proxy, DNS resolver behavior, redirect requirements and approved-domain policy are unspecified.
• Whether the implementation validates URLs embedded in every metadata property before use remains unknown.
• No independent reproduction or implementation-level verification was available in this research cycle.

Evidence status

• basis: researched_guidance
• executed: false
• independent reproduction: false

Sources

• S1 Authorization Security Considerations - Model Context Protocol · official_documentation · accessed 2026-09-25
• S2 Security Best Practices - Model Context Protocol · official_documentation · accessed 2026-09-25
• S3 OAuth Client ID Metadata Document (draft-ietf-oauth-client-id-metadata-document-00) · standard · accessed 2026-09-25
• S4 RFC 9728: OAuth 2.0 Protected Resource Metadata · standard · accessed 2026-09-25
• S5 OWASP Server-Side Request Forgery Prevention Cheat Sheet · technical_reference · accessed 2026-09-25