SW-MCP-010: No protected resource metadata, or issuer not validated

What it detects

The rule runs for servers that the probe classified as OAuth: with dynamic client registration, with Client ID Metadata Documents, or with the JWT bearer grant. It then applies five tests in order and reports the first one that fails, once, on the endpoint:

• no protected resource metadata was found;
• the resource metadata lists no authorization_servers;
• the authorization server metadata has no issuer, which RFC 8414 requires;
• the issuer differs from the one the address of the metadata implies, with the origin and any trailing path compared;
• the resource is not the endpoint itself or a parent path of it on the same origin.

Addresses are compared after lowercasing and after dropping a default port and a trailing slash, and a path counts as a parent only at a segment boundary, so /mc does not cover /mcp. The evidence names the failed test.

Why it matters

Resource metadata is how a client learns which authorization server may issue tokens for a server, and the issuer check is how it knows the answer was not substituted. If either is missing or inconsistent, a client has to guess, or may accept tokens from the wrong party, and the same checks protect against a look-alike address pointing at a different resource. The scanner maps this rule to OWASP MCP07, Insufficient Authentication & Authorization, and to NIST SP 800-53 control IA-5, Authenticator Management.

Example

This recorded probe shows a server that supports Client ID Metadata Documents at its authorization server and publishes no protected resource metadata:

probe.json

{
  "endpoint": "https://mcp.example.invalid/mcp",
  "reachable": true,
  "unauthenticated_status": 401,
  "www_authenticate": "Bearer realm=\"mcp\"",
  "auth_server_metadata": {
    "issuer": "https://auth.example.invalid",
    "metadata_url": "https://auth.example.invalid/.well-known/oauth-authorization-server",
    "registration_endpoint": null,
    "client_id_metadata_document_supported": true,
    "grant_types_supported": [
      "authorization_code"
    ]
  }
}

A server check judges what a probe recorded, not files. The recorded probe above is read the way the scanner's README describes under Evaluating an MCP server probe.

How to fix

Publish the protected resource metadata at the address that the 401 answer names in its WWW-Authenticate header. Its resource must be your endpoint or a parent path of it, and authorization_servers must list the issuer. The issuer in the authorization server's own metadata must equal the address it is served for. See the OAuth and iss items of the migration checklist.

If it is a false positive

A server behind a proxy that rewrites addresses may publish a resource or an issuer that differs from the public one. The rule compares what the probe saw with the address it probed, so such a difference is a real mismatch for a client that connects to that address. Accept the finding only after you have checked that real clients succeed.

If the finding is not a problem in your case, accept it with a note: in the dashboard a manager or owner can accept a finding and the note is kept with it; with the scanner on its own, add it to the baseline file with a reason and an expiry date.

Related rules

• SW-MCP-002: Static key authentication instead of OAuth
• SW-MCP-003: OAuth dynamic client registration (deprecated; use Client ID Metadata Documents)