Direct answer
Server-side request forgery (SSRF) happens when a caller can make a server send an unintended network request. Start with features that fetch URLs, then establish which destinations the server should be allowed to reach and verify that boundary with controlled test endpoints.
Map server-side URL fetchers
Link previews, document importers, image proxies, and webhook delivery can all make outbound requests. Identify whether the product needs a fixed destination set or arbitrary public destinations. That decision changes how application validation and network restrictions should work.
Reference: OWASP Server Side Request Forgery Prevention Cheat Sheet.
Use endpoints you control
An authorized test receiver can log a unique marker and show that a server made a request. Give each assessment run a distinct marker and record the feature invocation time. Keep the receiver free of customer data and avoid requesting cloud metadata or internal services unless explicitly included.
- Agree allowed destination classes before running checks.
- Correlate receiver logs with the application request.
- Separate browser-originated fetches from server-originated requests.
Check destination changes
A validated initial URL can lead elsewhere through a redirect or a later DNS resolution. Review how the fetcher handles redirects and how it validates the actual connection destination. A fixed business integration should not silently become a general-purpose network client.
Reference: OWASP Server Side Request Forgery Prevention Cheat Sheet.
Describe the reachable boundary
A callback proves a request reached the test receiver. It does not prove access to a database, a metadata credential service, or another tenant. Report the observed destination, method, request data, response exposure, and any tested restrictions separately.
- Retest the denied destination class with a safe fixture.
- Preserve a legitimate import or webhook delivery test.
- Review outbound controls as well as URL validation code.
Assessment limits
Out-of-band callbacks may be delayed, retried, or produced by a proxy. Internal reachability and credential access need independent evidence and explicit scope. A public callback alone does not justify the highest possible SSRF impact.
Frequently asked questions
Does URL syntax validation prevent SSRF?
A syntactically valid URL can still point at an unintended destination. Review the allowed host or address policy and the actual outbound connection.
Should every URL fetcher use an allowlist?
A fixed integration can usually define allowed destinations. A public URL importer needs a different design that restricts unsafe destination classes and enforces network boundaries.
What evidence confirms a server-side request?
A unique marker in controlled receiver logs, correlated with the tested feature, supports that conclusion. Record whether a browser, gateway, or background worker could also have made the request.
Primary sources and further reading
These guides combine published security guidance with practical assessment planning. Adapt checks to the owner's policy, environment, and authorized scope.