SSRF and Egress Security

Pathrule5 Rules • 1 Memory • 1 Skill

Server-side request forgery turns image fetchers, webhooks, importers, previews, and integrations into paths toward internal services and cloud metadata. This bundle constrains schemes and destinations, validates resolved addresses, rechecks redirects, limits response handling, and enforces network egress. Unlike the broad Web Security pattern, it focuses on outbound requests initiated from attacker-influenced input.

Suggested path map

Pathrule places each piece on the matching path, so your assistant only sees it where it belongs. This is the scoping you get on import; you can adjust it in your workspace.

/ workspace root

src/

network/

fetch/

Parse once and allow only required URL schemes and forms

Validate every resolved address before connection

Redirects repeat the complete destination check

test-ssrf-boundary

integrations/

Outbound fetch is a capability, not a reusable convenience helper

Untrusted fetch capability has an accountable usage budget

infra/

egress/

The fetcher runs behind enforced network and response limits

Rules

Parse once and allow only required URL schemes and forms/src/network/fetchhighstrictA strict URL parser produces the canonical destination, and policy rejects every scheme, credential form, port, and hostname not required by the feature.

1	Do not secure outbound requests with substring checks or regular expressions over the raw URL. Parse with one well-tested library, reject parse ambiguity and embedded credentials, normalize the hostname deliberately, and allow only the schemes and ports the feature needs. Most remote-content features should accept HTTPS only.
2
3	- Reject non-network schemes such as file, data, gopher, ftp, and runtime-specific handlers.
4	- Handle IPv4, IPv6, integer, hexadecimal, octal, encoded, trailing-dot, Unicode, and mixed-case host representations through canonical parsing and tests.
5	- Prefer a destination allowlist for known integrations and a narrow deny policy only when arbitrary public hosts are a true product requirement.
6	- Keep the validated URL object through connection setup instead of reparsing or concatenating later.
7
8	Verification: Run a corpus of alternative localhost, private-address, credential, port, and parser-confusion forms; confirm every equivalent forbidden destination is rejected.

Validate every resolved address before connection/src/network/fetchhighstrictAll A and AAAA results are checked against destination policy, and the connection cannot switch to an unvalidated address.

1	A hostname string that looks public can resolve to loopback, private, link-local, multicast, reserved, documentation, or cloud metadata space. Resolve the canonical host through a controlled resolver, inspect every IPv4 and IPv6 result, and reject the request if any candidate violates policy or if the connector might choose a different unvalidated answer.
2
3	- Apply explicit IP range classification rather than a short list of familiar private prefixes.
4	- Bind or otherwise verify the chosen connection address to reduce DNS rebinding between validation and connect.
5	- Restrict resolver search paths and internal DNS exposure for untrusted arbitrary-host features.
6	- Treat resolution failure, mixed public and private answers, and unsupported address forms as denial.
7
8	Verification: Test direct addresses, mixed A and AAAA answers, rebinding behavior, internal names, metadata ranges, and resolution races; confirm the socket reaches only an approved address.

Redirects repeat the complete destination check/src/network/fetchhighstrictAutomatic redirects are disabled or each Location target is parsed, resolved, authorized, and counted before another request is sent.

1	A permitted public URL can redirect to an internal address, another scheme, an unexpected port, or a long redirect chain. Disable automatic redirect following whenever the feature does not need it. When redirects are required, treat each Location as a new untrusted URL and repeat parsing, scheme, port, hostname, DNS, and IP checks before connection.
2
3	- Set a small redirect limit and detect loops using canonical destinations.
4	- Do not forward authorization headers, cookies, client certificates, or signed request data across origins.
5	- Apply the same timeout, response-size, content-type, and egress policy on every hop.
6	- Record safe destination categories and rejection reasons without logging secrets embedded in input.
7
8	Verification: Redirect a public host through multiple encodings to loopback, metadata, another scheme, and a second origin; confirm no forbidden hop receives a request or credential.

The fetcher runs behind enforced network and response limits/infra/egresshighstrictNetwork policy blocks internal destinations while the client bounds connect time, total time, bytes, decompression, content type, and concurrency.

1	Application validation can regress, so the runtime that performs untrusted fetches must also lack network reach to sensitive internal services and metadata endpoints. Place the capability in an isolated worker or workload with the narrowest outbound policy, no ambient cloud credentials, no internal service discovery, and a dedicated identity.
2
3	- Enforce connect, read, and total deadlines plus maximum redirects, headers, compressed bytes, decompressed bytes, and concurrent requests.
4	- Stream into bounded storage and stop before parsing unexpected or oversized content.
5	- Resolve and connect through the approved proxy or egress gateway so policy cannot be bypassed by a custom client.
6	- Expose only the minimal normalized result to callers, never raw internal headers, socket errors, or timing detail.
7
8	Verification: Bypass application checks in a test environment and attempt internal, metadata, oversized, slow, compressed-bomb, and high-concurrency requests; confirm infrastructure contains each case.

Untrusted fetch capability has an accountable usage budget/src/integrationsmediumstrictCallers are authenticated, authorized, rate limited, metered, and attributable before they can spend outbound network and parsing resources.

1	Even a destination-safe fetcher can become a scanning, bandwidth, storage, or denial-of-service primitive. Require an authenticated caller or narrowly scoped workload identity, authorize the named fetch capability, and charge each request to a tenant, user, job, or integration budget before network work begins. Anonymous features need a separately constrained public abuse policy.
2
3	- Limit request rate, concurrent work, total bytes, unique destinations, retries, and retained output by accountable subject.
4	- Prevent one redirect chain, batch request, or retry loop from escaping the original budget.
5	- Expose safe rejection categories and correlation ids while hiding target resolution and internal network detail.
6	- Alert on repeated forbidden destinations, limit exhaustion, unusual host diversity, and policy bypass attempts.
7
8	Verification: Distribute abusive requests across redirects, batches, retries, tenants, and worker restarts; confirm consumption stays bounded and attributable.

Memories

Outbound fetch is a capability, not a reusable convenience helper/src/integrationsFeatures receive purpose-specific fetch operations with fixed policy instead of direct access to a general HTTP client.

1	A general fetch(url, options) helper spreads SSRF review across every caller and lets later code add methods, headers, bodies, redirects, or destinations the original feature never required. Expose purpose-specific operations such as fetchPublicImage, deliverWebhookToVerifiedEndpoint, or readApprovedFeed with policy fixed inside the boundary.
2
3	Give each capability its own allowed methods, schemes, ports, destination model, credentials, request body, redirect behavior, content types, size limits, and normalized result. Keep vendor API clients separate from arbitrary public-content fetchers. Review any new option as an expansion of network authority. See /src/network/fetch for canonical validation and /infra/egress for the independent containment layer.

Skills

test-ssrf-boundary/src/network/fetchExercise parser confusion, DNS answers, redirects, response limits, credentials, and infrastructure egress against a controlled malicious server.

1	---
2	name: test-ssrf-boundary
3	description: Test an outbound URL-fetching boundary against SSRF and resource-exhaustion cases.
4	---
5
6	# Test SSRF Boundary
7
8	1. Inventory every caller, accepted input form, HTTP method, header, credential, scheme, port, redirect behavior, parser, resolver, proxy, and runtime network path.
9	2. Run canonicalization cases for IPv4, IPv6, encoded and alternate numeric forms, Unicode names, credentials, fragments, ports, and non-HTTP schemes.
10	3. Serve controlled DNS answers that are private, mixed, changed between lookup and connect, or redirected through several hops.
11	4. Attempt metadata and internal services, slow responses, excessive headers, large and highly compressed bodies, wrong content types, redirect loops, and concurrency pressure.
12	5. Confirm both application policy and infrastructure deny safely, record the actual connected address, and retain regression fixtures for every bypass found.
13
14	A passing test proves the network destination, not merely the input string, stayed inside policy.

Why this pattern

Agents pass user-provided URLs to a general HTTP client, block only obvious localhost strings, follow redirects automatically, and expose internal response content or timing.

Built for Teams building URL previews, webhook testers, media importers, feed readers, document fetchers, proxies, or server-side integrations.

Keeps your assistant from:

Fetching loopback, private, link-local, metadata, or internal service addresses
A public-looking hostname resolving or redirecting to a forbidden destination
Large, slow, compressed, or unexpected responses exhausting the fetch service

View as markdown

License: Apache-2.0
Version: 1.0.0
Updated: 2026-08-25