SSRF assessment: validate outbound trust boundaries safely

Sources checked: 29 October 2026. This article contains FailSafe's analysis and proposed validation workflow; linked sources support the reported facts.

An SSRF assessment should identify which user-influenced actions cause a server to make an outbound request, then evaluate the intended destination policy with controlled infrastructure. It should avoid probing internal systems or cloud metadata as a shortcut to evidence.

OWASP describes application and network controls for server-side request destinations. OWASP SSRF Prevention Cheat Sheet provides the underlying reference. The assessment design below is an original defensive example, not a report of a customer incident.

Inventory the fetchers and their authority

Common business features include link previews, imports, webhook delivery, document conversion, and remote image retrieval. Record which component performs each fetch and what network access or credentials it holds. Determine the allowed destination classes and whether redirects are permitted. An externally reachable URL may later resolve or redirect elsewhere, so review the complete destination decision. Ask operations staff which network controls constrain the component before planning any behavior test. Written authorization for an application does not automatically authorize testing unrelated internal services.

Use two owned callback destinations

Provide approved HTTPS endpoints under assessment-team control, with harmless marker responses and no sensitive content. Demonstrate an allowed retrieval and evaluate a destination category the application policy should reject. Any redirect case should remain between owned endpoints and follow the explicit scope. Monitor only whether the expected callback occurred and which component made it. Do not use real internal addresses, metadata services, or credential-bearing destinations. This approach can show a policy mismatch without extracting secrets or expanding the assessment into a cloud compromise exercise.

Gather route and decision evidence

Record the initiating user, feature, sanitized destination category, redirect handling, authorization decision, and callback observations. Ask the owner to correlate outbound proxy or network logs. A browser-side fetch is a different boundary from a server-side fetch, so establish which occurred. If the application blocks the first URL but a worker later retrieves it, include both decisions. Explain the demonstrated reachability precisely. A callback to an owned external host does not prove access to an internal database, cloud credential service, or another tenant.

Retest policy at the right layer

Changes may belong in URL parsing, destination validation, redirect handling, network egress, or the authority of the fetching worker. Review the combined design rather than recommend a single string filter. Retest valid imports and blocked categories after remediation. Document untested protocols and integrations. A safe boundary test deliberately leaves some potential impact unexercised; the report should say so. For recurring agentic assessments, allowlist the testing callback infrastructure and require a stop when an unexpected destination or sensitive response appears.

A useful assessment artifact

Keep a fetcher register naming each feature, its execution identity, allowed destination category, redirect policy, and egress owner. A new document converter or import worker can then be assessed against the same explicit boundary before it becomes externally available.

Plan an assessment

Discuss the authorized scope and required evidence with FailSafe SWARM. For a business evaluating an initial engagement, review the first-pentest offer and confirm scope before purchase.