What is SSRF testing?

SSRF testing checks whether untrusted input can make an application send requests to unintended destinations, such as loopback, private, or link-local addresses. It covers parsing, DNS resolution, redirects, and the final connection target.

Is a URL allowlist enough to prevent SSRF?

The OWASP SSRF Prevention Cheat Sheet recommends allowlists when the application knows which systems it must contact. Validation still has to apply to every redirect hop and to the address the client actually connects to, and network policy should back it up.

How do you test SSRF through redirects and DNS?

Run a controlled redirect server and check every hop against the same destination policy with a redirect limit. For DNS, resolve a test hostname to an allowed address, then change the answer to a blocked range and confirm the client does not connect to it.

How does Factory catch SSRF in pull requests?

Factory security review traces untrusted input across network boundaries in two passes, first producing candidates and then validating reachability and exploitability. Findings are reported inline with P0 to P3 severity and a suggested fix.

All articles

AI Coding Agents

Security

How to test for SSRF in agent-written request code

September 28, 2026 - 4 minute read

To test for server-side request forgery (SSRF), send every outbound request path URLs that point at loopback, private, link-local, and other prohibited addresses, including through redirects and changing DNS answers, and assert that none of those requests reach a socket. For coding agent changes, run those tests in CI and add a security review of the pull request.

SSRF testing checks whether untrusted input can make an application send requests to unintended destinations. Coding agent changes often add webhook delivery, URL previews, importers, image fetchers, or integration callbacks. Each feature creates an outbound request path that needs explicit destination rules and tests.

The OWASP SSRF Prevention Cheat Sheet recommends allowlists when the application knows which systems it must contact. It also separates validation of IP addresses, domain names, URLs, and network access. A string check alone cannot enforce the full boundary.

Map SSRF testing to the request lifecycle

Trace the value from user input to the network call. Record parsing, normalization, DNS resolution, redirects, proxy behavior, and the final socket destination. Validation must apply to the same interpretation the HTTP client uses.

Create positive fixtures for every permitted scheme, host, and port. Then cover loopback, link-local, private, multicast, and otherwise reserved addresses as required by the application’s network policy. Include IPv6 and unusual but valid textual forms. A denylist of familiar hostnames misses alternate address representations.

If arbitrary public destinations are a product requirement, enforce the boundary in network policy as well as application code. The test plan should identify which layer blocks each prohibited destination.

Test redirects and DNS behavior

A permitted URL can redirect to a prohibited address. Run a controlled redirect server and verify every hop against the same destination policy. Set a redirect limit and reject unsupported schemes instead of passing them to a general-purpose client.

DNS adds another state change between validation and connection. Resolve a test hostname to an allowed address, then simulate a response that changes to a blocked range. Verify whether the HTTP client reuses the validated address or performs a fresh resolution. The result should match the documented threat model.

The same check has to run on every hop. The diagram shows the loop a request should follow, with each redirect sent back through parsing, resolution, and the destination decision.

Proxies and service meshes can change the apparent destination. Run at least one test in the deployment network when local routing differs from production.

Give a coding agent precise SSRF checks

Scope the task to named request entry points and shared URL helpers. Provide the approved destination policy, existing security tests, and the command that runs them. Ask for proof that each redirect is validated and that errors do not reveal internal addresses.

Review SSRF test evidence

Keep test servers local and deterministic. A security test should never probe real cloud metadata services or internal production addresses. Bind controlled listeners to test interfaces and assert that prohibited requests never arrive.

Review the final connection target, not only the input string. Log a redacted destination category, decision, and redirect count for failed fixtures. The evidence should show that the boundary held without exposing credentials, query values, or internal topology.

How Factory flags SSRF risks in pull requests

Factory is a platform for running a software factory, where agents called Droids take work from a signal to a reviewed pull request. For outbound request code, Factory adds a security reviewer to the pull request and limits what the Droid itself can reach while it works.

Security review traces the request path. Factory's security review follows changed data flows across authentication, validation, network, and filesystem boundaries. It works in two passes. The first pass traces untrusted input and produces candidate vulnerabilities. The second pass re-checks each candidate for reachability, exploitability, and existing controls, which keeps unreachable URL helpers from filling the pull request with noise. Each finding gets a severity level from the published scale.

Severity	Level	Examples
Critical	`P0`	RCE, hardcoded production secret, auth bypass, unauthenticated admin endpoint
High	`P1`	SQL injection behind auth, stored XSS, sensitive-data IDOR, very new dependency
Medium	`P2`	CSRF on state-changing operations, information disclosure, prompt injection behind auth
Low	`P3`	Minor security hardening with a concrete but low-impact exploit path

The review can run on every non-draft pull request with automatic_security_review: true, or on demand with an @droid security comment. A security-review-guidelines skill can point it at the repository's outbound request sinks, URL helpers, and redirect settings.

The Droid's own network is limited too. Agent Safety & Controls include a built-in sandbox with an allowedDomains list for command network access. When a Droid runs the SSRF suite, that list keeps a misconfigured test from probing a real internal address. Executable tests and the review cover different questions, so keep both as required checks.

Frequently asked questions

What is SSRF testing?: SSRF testing checks whether untrusted input can make an application send requests to unintended destinations, such as loopback, private, or link-local addresses. It covers parsing, DNS resolution, redirects, and the final connection target.
Is a URL allowlist enough to prevent SSRF?: The OWASP SSRF Prevention Cheat Sheet recommends allowlists when the application knows which systems it must contact. Validation still has to apply to every redirect hop and to the address the client actually connects to, and network policy should back it up.
How do you test SSRF through redirects and DNS?: Run a controlled redirect server and check every hop against the same destination policy with a redirect limit. For DNS, resolve a test hostname to an allowed address, then change the answer to a blocked range and confirm the client does not connect to it.
How does Factory catch SSRF in pull requests?: Factory security review traces untrusted input across network boundaries in two passes, first producing candidates and then validating reachability and exploitability. Findings are reported inline with P0 to P3 severity and a suggested fix.

Talk with Factory

Discuss your team’s software development, privacy, or deployment requirements.