AI Coding Agents
Security
SSRF testing for coding agent network changes
September 28, 2026 - 2 minute read
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.
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.
Factory’s Security Review applies STRIDE, OWASP, and supply-chain methods to pull requests or full repositories. Repository guidance can direct the review to outbound request sinks, URL parsing, redirect handling, and network controls. That review complements executable SSRF tests rather than replacing them.
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.
