← All articles

What Is SSRF (Server-Side Request Forgery) and How Do You Prevent It?

8 September 2026

What Is SSRF (Server-Side Request Forgery) and How Do You Prevent It?

Server-Side Request Forgery (SSRF) is when an application fetches a URL derived from user input on the server side, and the attacker can control that URL. The result: access, with the server’s identity, to an internal network normally closed to the outside, to cloud metadata services, or to local services.

How it arises

Applications frequently fetch a URL: remote image previews, webhook validation, PDF generation, an “import from URL” feature. If the application does not sufficiently restrict the address it fetches, an attacker can point it at internal targets:

https://yourapp.com/preview?url=http://169.254.169.254/latest/meta-data/

Here the attacker targets the cloud provider’s metadata endpoint instead of an external image. In misconfigured environments, this can leak sensitive information such as temporary access keys through the server.

Impact

  • Internal network discovery and access: internet-closed admin panels, databases and internal APIs may become reachable via the server.
  • Cloud metadata leakage: identity/access credentials, especially with older metadata mechanisms that do not require a session token.
  • Local services and file schemes: http://localhost, and in some cases file://, may reach internal resources.

Defences

SSRF defence should be allowlist-based; a denylist (“block bad addresses”) is bypassed with IP-encoding tricks and redirects.

  1. Restrict the target with an allowlist of the domains/endpoints the app legitimately needs.
  2. Block internal IP ranges and the metadata IP. Verify the resolved IP is not in private ranges (10/8, 172.16/12, 192.168/16, 127/8) or 169.254.169.254.
  3. Beware redirects and DNS rebinding. Validating only the first URL and blindly following redirects is bypassable; re-validate the IP at each hop or disable redirects.
  4. Enforce secure metadata mode in the cloud (token-only access), so metadata is protected even if SSRF exists.
  5. Allow only needed schemes (https); reject file, gopher, ftp.

Summary

SSRF’s root cause is the server trusting a user-controlled address to make a request. The strongest defence is limiting the target to an allowlist, blocking internal/metadata IPs, and re-validating redirects at every hop. Secure cloud metadata mode is a critical second layer.

Sources: OWASP SSRF Prevention Cheat Sheet, PortSwigger: SSRF, CWE-918.

Are your URL-fetching endpoints exposed to SSRF? CyberTestify’s active verification runs harmless SSRF/parameter probes on discovered entry points.