SSRF Defense Checklist
Score your defenses against Server-Side Request Forgery (SSRF). Work through a grouped checklist of real mitigations — URL allowlisting, blocking the cloud metadata address (169.254.169.254) and private ranges, validating the resolved IP against DNS rebinding, redirect safety, IMDSv2 and network egress filtering — mark each as met, partial or not met, and get a coverage score, prioritized remediation and an exportable hardening report. It is an educational self-assessment: nothing is sent anywhere and the tool makes no requests of its own.
Educational guidance and a self-assessment only. This tool makes no network requests and cannot test or reach any endpoint. Assess and harden only systems you are authorized to.
URL validation & allowlisting
Decide what the server is allowed to fetch before it fetches anything.
- Enforce an allowlist of permitted destination hosts and schemescritical
The fetcher may only reach an explicit set of hosts/domains over an explicit set of schemes. Allowlists beat blocklists — a denylist of "bad" ranges is almost always bypassable.
- Validate and canonicalise user-supplied URLs; never pass a raw URL to a server-side fetcherhigh
User input that becomes a server request is the root cause of SSRF. Parse the URL, reject malformed or obfuscated forms (decimal/octal/hex IPs, embedded credentials, unicode tricks), and rebuild it from validated parts.
- Reject non-HTTP(S) schemes (file://, gopher://, ftp://, dict://, data:)high
Many SSRF escalations rely on exotic schemes to read files or speak to internal services. Permit only the schemes you actually need — usually just https.
Block internal address space
Even an allowed hostname can resolve to an internal IP — block those at the IP level.
- Block link-local and cloud-metadata addresses (169.254.169.254, 169.254.0.0/16, fd00:ec2::254)critical
The cloud instance-metadata service at 169.254.169.254 is the classic SSRF target — reaching it can expose IAM credentials. Block the whole link-local range, IPv4 and IPv6.
- Block loopback addresses (127.0.0.0/8, ::1)high
Loopback lets a request hit admin panels, debug endpoints and local databases bound to localhost.
- Block RFC 1918 private ranges (10/8, 172.16/12, 192.168/16) and IPv6 ULA (fc00::/7)high
Private ranges are where internal services live. If the fetcher can reach them, SSRF becomes an internal port scanner and pivot.
- Block other special-use ranges (0.0.0.0/8, 100.64.0.0/10 CGNAT, broadcast, multicast)medium
0.0.0.0 and carrier-grade NAT or shared ranges are frequently overlooked and can still route to local or shared infrastructure.
DNS & redirect safety
Close the gap between "the name looked fine" and "the connection went somewhere else".
- Resolve DNS and validate the resolved IP — not just the hostnamecritical
A hostname on your allowlist can resolve to an internal or metadata IP. Validate the actual resolved address against your deny ranges every time.
- Connect to the validated IP to close the TOCTOU / DNS-rebinding gaphigh
If you validate a name, then let the HTTP client resolve it again at connect time, an attacker can rebind DNS between the two lookups. Pin the connection to the address you validated.
- Disable HTTP redirect-following, or re-validate the target after each redirecthigh
A permitted URL can 3xx-redirect to 169.254.169.254 or an internal host. A client that blindly follows redirects reintroduces the vulnerability you just closed.
Cloud metadata hardening
Make the metadata service itself resistant even if a request reaches it.
- Require IMDSv2 (session token + hop limit) on AWS and disable IMDSv1critical
IMDSv2 requires a PUT to obtain a token and a low IP hop limit, which defeats most SSRF reads of the metadata service because a simple GET (as SSRF typically produces) no longer returns credentials.
- Scope instance / workload identity to least privilegemedium
If metadata credentials are ever exposed, their blast radius is only as large as the attached role. Minimal permissions limit what a leaked token can do.
Defense in depth
Assume the app-layer check will one day be bypassed.
- Enforce egress filtering at the network layer, not only in app codehigh
A firewall, egress proxy or security group that denies outbound traffic to internal and metadata ranges catches SSRF even when an application-code check is missed or bypassed.
- Isolate the fetching service (own subnet/namespace, no route to metadata)medium
Running the component that makes outbound requests in a segment with no path to the metadata endpoint or internal admin services removes the target entirely.
- Log and alert on blocked outbound attempts to internal rangeslow
A spike in requests toward 169.254.169.254 or RFC 1918 space is a strong SSRF-exploitation signal. Blocking silently means you never learn you are being probed.
Scored entirely in your browser — nothing is uploaded. This tool holds no credentials, makes no outbound requests, resolves no hostnames and has no URL-fetching capability of its own; it only scores the answers you tick.
What this tool is
- An interactive self-assessment for defending against SSRF (Server-Side Request Forgery): tick each mitigation as met, partial or not met and get a weighted coverage score.
- Covers the controls that actually matter — URL allowlisting, blocking link-local/metadata (169.254.169.254) and RFC 1918 private ranges, validating the resolved IP against DNS rebinding, redirect re-validation, IMDSv2 and network-layer egress filtering.
- Produces a prioritized remediation list (critical gaps first) plus an exportable plain-text hardening report you can copy or download.
- Educational guidance only — it makes no network requests, resolves no hostnames and has no URL-fetching capability. It cannot perform or test SSRF against any system.
- Everything runs client-side in your browser; nothing you tick is uploaded or stored on a server.
What is server-side request forgery?
Server-Side Request Forgery (SSRF) is a web vulnerability in which an attacker coerces a server into making HTTP (or other-protocol) requests to a destination of the attacker's choosing. It shows up wherever an application accepts a URL or hostname and then fetches it server-side: webhook targets, "fetch this image/avatar from a URL", URL previews and link unfurling, PDF or screenshot generators, document/feed importers, and integrations that proxy a user-supplied address. Because the request comes from the server, it inherits the server's network position and can reach things the public internet cannot — which is exactly what makes SSRF dangerous. It is tracked as A10:2021 in the OWASP Top 10.
How an SSRF attack works
The application exposes a feature that takes a URL — say POST /fetch?url=…. The attacker supplies not a normal external URL but an internal one: http://127.0.0.1:8080/admin, http://10.0.0.5:6379/ to reach an internal Redis, or the cloud metadata endpoint. The server resolves the host and makes the request from inside the trusted network, then (in basic SSRF) returns the response to the attacker. Naive filters are routinely bypassed with alternate IP encodings (decimal, octal, hex), [::1], DNS names that resolve to internal IPs, and redirects from an allowed host to an internal one — which is why SSRF defense has to validate the resolved IP and re-check after every redirect, not just pattern-match the string.
The cloud-metadata attack (169.254.169.254 / IMDSv1)
The highest-impact SSRF target in the cloud is the instance metadata service (IMDS) at the link-local address 169.254.169.254. On AWS, requesting http://169.254.169.254/latest/meta-data/iam/security-credentials/<role> under the legacy IMDSv1 returns temporary IAM credentials for the instance's role — a single reflected SSRF response can hand an attacker live cloud keys, which is how SSRF escalates into full account compromise. IMDSv2 mitigates this: it requires a two-step, token-based flow (a PUT to obtain a session token first) and a low IP hop limit, neither of which a plain SSRF GET can satisfy. Requiring IMDSv2, and blocking the whole 169.254.0.0/16 range at your validation and egress layers, are the two controls that most directly defuse this class of attack.
Blind vs basic SSRF
- Basic (in-band) SSRF. The response from the forged request is returned to the attacker, so they can directly read internal pages, metadata and service responses. This is the easiest to exploit and the easiest to spot.
- Blind SSRF. The response is not reflected back, but the server still makes the request. Attackers use timing to port-scan and map the internal network, trigger state-changing requests against internal APIs, or exfiltrate data through out-of-band DNS/HTTP callbacks. The impact does not depend on seeing the response — so the same preventive controls apply to both.
Real-world impact
SSRF is not theoretical. It has been used to read cloud instance credentials and pivot into cloud accounts, to reach internal admin panels and unauthenticated internal services, to port-scan and fingerprint internal networks, and to turn a benign-looking "fetch a URL" feature into a foothold behind the perimeter. Its severity comes from where the request originates: a control that trusts "traffic from our own servers" is exactly the control SSRF subverts. That is why the defenses below are layered — allowlisting and IP validation in the app, redirect and DNS-rebinding safety at the HTTP client, IMDSv2 at the cloud platform, and egress filtering and isolation at the network — so that no single bypass re-opens the whole path.
Use responsibly: this page is educational guidance and a self-assessment. It performs no requests and cannot test any endpoint. Assess, harden and test SSRF defenses only on systems you own or are explicitly authorized to test.
Frequently asked questions
What is server-side request forgery (SSRF)?
Server-Side Request Forgery (SSRF) is a vulnerability where an attacker makes a server send HTTP (or other) requests to a destination the attacker chooses. The application takes a URL or hostname — often from user input such as a webhook target, a "fetch this image", a PDF/URL preview feature, or an import-from-URL field — and the server dutifully requests it. Because the request originates from the server, it can reach internal services, cloud metadata endpoints and other resources that are not exposed to the public internet, bypassing network perimeter controls. SSRF is in the OWASP Top 10 (A10:2021).
How do I prevent SSRF?
There is no single switch; SSRF prevention is layered. Validate and canonicalise user-supplied URLs and enforce an allowlist of permitted hosts and schemes rather than a denylist. Resolve the hostname and validate the actual resolved IP against a deny set (link-local/metadata, loopback, RFC 1918 private ranges, and other special-use ranges), then connect to that validated IP so DNS cannot rebind between check and connect. Disable HTTP redirect-following or re-validate after every redirect. On AWS, require IMDSv2 so a simple SSRF GET cannot read instance credentials. Finally, enforce egress filtering at the network layer and isolate the fetching service, so the app-layer check is not the only thing standing between an attacker and your internal network. This checklist walks through each of those controls.
Why is 169.254.169.254 such a common SSRF target?
169.254.169.254 is the link-local address of the cloud instance metadata service (IMDS) on AWS, GCP, Azure and others. A server running in the cloud can query it to read instance configuration — and, critically, temporary IAM/role credentials. If an attacker can make a vulnerable server request http://169.254.169.254/latest/meta-data/iam/security-credentials/ (on AWS IMDSv1), the response hands back live cloud credentials, which is how many SSRF findings escalate into full cloud-account compromise. Blocking the entire 169.254.0.0/16 link-local range at the validation and egress layers, and requiring IMDSv2 (which needs a session token and a low IP hop limit that a plain SSRF GET cannot satisfy), are the two defenses that matter most here.
What is the difference between basic and blind SSRF?
In basic (or in-band) SSRF, the response from the forged request is returned to the attacker, so they can directly read internal pages, metadata or service responses. In blind SSRF, the response is not reflected back — the attacker cannot see it — but the server still makes the request. Blind SSRF is still dangerous: it can be used to port-scan and map the internal network by timing responses, to trigger state-changing requests against internal services, or to exfiltrate data through side channels such as out-of-band DNS/HTTP callbacks. Because the impact does not depend on seeing the response, the same preventive controls — allowlisting, IP validation and egress filtering — apply to both.
Does this tool test my site for SSRF or make any requests?
No. This is purely an educational reference and self-assessment. It runs entirely in your browser, makes no network calls of any kind, resolves no hostnames and has no URL-fetching capability — so it cannot be used to perform or test SSRF against any system, including your own. It only scores the mitigations you tick and assembles a hardening report from your answers. Validate your actual defenses with authorized testing against systems you own or are permitted to test.