How do you test server-side request forgery prevention?

You test server-side request forgery prevention by attempting to make the server call internal, metadata, and other non-approved destinations through any URL-fetching feature. Check that only allowlisted targets are reachable, redirects are controlled, DNS rebinding is handled, and responses do not expose internal network details or credentials.

What SSRF testing should prove, not just trigger

Effective SSRF testing is not about finding any outbound request, it is about proving the application can no longer be steered into trusted internal destinations. The test should confirm that user-controlled fetches are constrained to approved targets, that redirects and alternative IP forms are resisted, and that the application does not reveal network topology, cloud metadata, or credential material when the request path is abused.

A useful baseline is to exercise every feature that fetches a URL, callback, image, webhook, import, preview, PDF, or link target, because SSRF often hides inside ordinary business functions rather than an obvious “fetch” endpoint.

For a practical testing sequence, start with a small matrix of internal, loopback, link-local, and metadata-service destinations, then verify the application rejects them consistently across schemes, hostnames, ports, and payload encodings. The point is to prove the control is enforced before any network call is made, not to rely on network perimeter behaviour after the request has already left the application.

How to validate allowlists, redirects, and DNS handling

Allowlist testing should confirm that the application resolves the intended destination after normalisation and still blocks lookalike hosts, userinfo tricks, decimal or hexadecimal IP encodings, and hostnames that resolve to internal ranges. If the control relies on DNS, test whether the application re-resolves names on each request and whether it binds the hostname check to the final destination rather than the first lookup result.

Redirect handling deserves separate testing because an apparently safe first hop can still land on an internal target if the client follows redirects too freely. Use both same-host and cross-host redirects, then verify that the application either refuses redirects entirely or re-evaluates the destination after every hop. If the application accepts remote content, confirm that it does not pass through credentials, cookies, or internal headers to the redirected request.

DNS rebinding tests are especially important when the application validates a hostname once and then reuses the resolved address later. A correct control should prevent a benign public name from being rebound to an internal IP after validation, and it should not trust DNS responses that change between resolution and connection time.

What a strong SSRF test exposes when the control fails

When SSRF prevention is weak, the application may become a proxy into internal services, cloud instance metadata, or management endpoints that were never meant to be internet-reachable. That is why good testing looks for more than a simple 200 response, it checks whether the server can be induced to disclose internal banners, headers, service errors, or credentials and tokens from metadata-style endpoints. NHIMG’s SSRF Prevention Guide is useful here because it ties the control failures to allowlisting, egress filtering, and metadata abuse.

Failure mechanism: The application accepts attacker-controlled destinations, follows redirects without revalidation, or trusts DNS results that can be changed after validation, allowing the request to reach internal-only services or cloud metadata endpoints.

Impact: Successful SSRF can expose internal network details, service responses, temporary cloud credentials, or privileged paths that support further intrusion, lateral movement, or data access.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP API Security Top 10 addresses the attack and risk surface, while OWASP ASVS, CIS Controls v8 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
OWASP API Security Top 10	API7 — Server Side Request Forgery	SSRF testing directly targets API and web-service request handling.
Recommendation — Test every URL-fetching path for outbound request control and destination validation.
OWASP ASVS	V4 — API and Web Service	SSRF prevention is exercised through server-side web and API request flows.
	V13 — Configuration	Egress filtering, redirect policy, and metadata access depend on secure configuration.
Recommendation — Verify server-side request validation and outbound call restrictions in API flows. Harden outbound network and redirect settings to prevent unintended server-side calls.
CIS Controls v8	CIS-12 — Network Infrastructure Management	SSRF defenses rely on controlling outbound paths and internal network reachability.
	CIS-16 — Application Software Security	Testing SSRF prevention is an application security exercise against user-controlled fetches.
Recommendation — Restrict and monitor outbound connectivity to block access to internal destinations. Validate application controls that stop user-supplied URLs from reaching unsafe targets.
NIST SP 800-53 Rev 5	SC-7 — Boundary Protection	SSRF prevention depends on controlling network egress and segment boundaries.
	SI-10 — Information Input Validation	Allowlist and normalisation checks are core to blocking attacker-controlled URLs.
	CM-7 — Least Functionality	Blocking unnecessary outbound destinations supports SSRF resistance.
Recommendation — Enforce boundary controls that prevent servers from reaching prohibited destinations. Validate and normalise URL input before any server-side connection attempt. Disable unnecessary outbound request paths and external connectivity.

Practitioner Guidance

What to verify: Test the exact production request path, not a lab-only clone, because SSRF controls often differ between code paths, environments, and outbound proxy rules. Confirm that the application blocks private and link-local ranges after all normalisation steps, and that it handles redirects and DNS lookups consistently under load.

What to prioritise: Give first attention to features that accept full URLs or fetch remote content on behalf of a user, then to any integration that can reach internal services or metadata endpoints. If one of those paths can be coerced into a server-side request, treat it as the highest-risk place to focus remediation and retesting.

Practitioner takeaway: SSRF prevention is proven only when the application rejects every path to non-approved destinations, not when a single test payload happens to fail.