DEV Community

Rhumb
Rhumb

Posted on • Originally published at rhumb.dev

MCP Fetch SSRF Protection Checklist

#ai #security #mcp #programming

A URL tool can reach whatever the MCP server can reach.

If that server runs in a cloud, CI, laptop, VPC, or cluster, open fetch becomes a credential and internal-network boundary.

The safe default is to deny dangerous targets before the request leaves the runtime.

Fast answer

  • A fetch MCP server is not just a read tool. It is network egress running from wherever the agent host sits.
  • SSRF protection has to run before the HTTP request: parse the URL, resolve DNS, classify every resolved address, apply redirect policy, and deny metadata, loopback, private, IPv6 ULA, and in-cluster targets by default.
  • Allowing public URLs is not the same as allowing internal services. Internal fetch needs its own route card with caller, tenant, target, credential lane, quota owner, review owner, and receipt fields.
  • The pass/fail proof is paired: one allowed external URL and one denied neighbor such as 169.254.169.254 must travel through the same endpoint, gateway, retry, and trace path.

Operator rule

SSRF denial is a successful control outcome.

A blocked metadata or private-network request should not look like flaky networking. It should leave a typed policy receipt that proves which credential lane and target class were protected.

The production checklist

1. URL parse gate

Reject missing schemes, userinfo surprises, encoded host tricks, non-HTTP schemes, overlong inputs, and ambiguous normalization before DNS resolution.

2. DNS and IP classification

Resolve the hostname at request time, classify every A/AAAA result, and deny link-local, loopback, private, carrier-grade NAT, multicast, IPv6 ULA, and service-network addresses by default.

3. Redirect containment

Apply the same host and IP policy after every redirect. A safe first URL cannot redirect into metadata, loopback, or private infrastructure.

4. Credential-lane isolation

Record which server, cloud role, proxy, token, cookie jar, or provider credential would be exposed if the request were allowed.

5. Internal-route exception

If internal access is intentional, require a named route card with target host/CIDR, caller, tenant, purpose, review owner, credential lane, and quota owner.

6. Typed denial receipt

Return a policy denial with raw URL, normalized host, resolved IP class, rule id, blocked credential lane, and recovery hint instead of a generic network failure.

Denied neighbors

Pair every allowed URL with the target class that must fail closed.

Cloud metadata

Examples: 169.254.169.254, metadata.google.internal, instance-data, IMDS-style aliases.

Expected: deny before request; receipt names metadata/link-local policy and credential lane protected.

Loopback

Examples: 127.0.0.1, ::1, localhost, decimal/hex/octal host encodings.

Expected: deny before request; receipt shows normalized host and loopback classification.

Private network

Examples: 10.0.0.0/8, 172.16/12, 192.168/16, fd00::/8, Kubernetes service ranges.

Expected: deny unless a specific internal route card authorizes that target for the caller and tenant.

Redirect into private target

Examples: public URL returning 30x to metadata, loopback, or RFC1918 address.

Expected: re-run DNS/IP policy on redirect and deny with redirect hop preserved in trace.

Trace evidence

Fetch SSRF protection is only operator-grade if the denial is reconstructable. Store enough evidence to show the target was classified and blocked before any credential, proxy, cookie, or cloud role was exposed.

The receipt should include:

  • caller / tenant / workspace
  • tool route and endpoint family
  • raw URL and normalized URL
  • normalized host and port
  • DNS answers and selected address
  • IP class and policy rule
  • redirect chain and final target
  • credential lane or server role protected
  • quota / budget owner
  • policy decision and typed denial code
  • response size / timeout / retry envelope
  • receipt id and recovery hint

Internal exception card

Some agents legitimately need to reach internal services. That should never be granted by weakening public fetch policy.

Internal network access is a different route, not a checkbox. Give the internal lane its own route card, review owner, target scope, credential lane, and expiration.

Internal target / CIDR:
Caller / tenant / workspace allowed:
Business purpose:
Credential lane exposed:
Quota owner / retry ceiling:
Review owner:
Allowed methods and response size:
Forbidden neighboring targets:
Receipt fields:
Expiration / re-review date:
Enter fullscreen mode Exit fullscreen mode

Common misreads

SSRF defenses usually collapse in predictable places:

  • Calling fetch read-only even though the request originates from a privileged cloud or developer host.
  • Checking the hostname string but not resolved IPs, CNAME chains, redirects, or IPv6 results.
  • Denying 169.254.169.254 while allowing metadata hostnames, loopback aliases, or private-service DNS.
  • Letting retries or fallback proxies reissue the request without the same policy bundle.
  • Logging only request failure instead of the policy decision that protected a credential lane.
  • Treating internal network access as a boolean feature instead of a separate reviewed route.

Related operator guides

If you want the owned version with the route-hardening CTA, it is here: https://rhumb.dev/blog/mcp-fetch-ssrf-protection-checklist

Top comments (0)