SSRF Vulnerability Scanner

What is SSRF Vulnerability Scanner?

Server-Side Request Forgery (SSRF) is a vulnerability where an attacker tricks your server into making requests on their behalf. If your application takes a URL as input — to fetch a preview, import a file, call a webhook — and doesn't restrict where that URL can point, an attacker can aim it at places they could never reach directly: your cloud provider's metadata endpoint, internal admin panels, or local files on the server. The server, trusted inside your network, becomes the attacker's proxy.

What Nandix checks

• Cloud metadata endpoints (AWS IMDS, GCP metadata.google.internal, Azure IMDS)
• Internal network hosts — IPv4/IPv6 loopback and RFC 1918 private ranges across common ports
• Scheme abuse — file://, gopher://, dict:// URLs
• IP-obfuscation bypasses — decimal, hex, octal, shortened, URL-encoded, and @-embedded hosts
• Redirect chains that follow through to an internal host
• DNS-rebinding hostnames (nip.io style) that resolve to loopback

Probes

52 checks — Cloud Metadata 10 · Internal Network 18 · Bypass Techniques 10 · Scheme Abuse 6 · Redirect Chain 4 · DNS Rebinding 4

How it detects

Passive, response-only. After stripping the echoed payload from the body, it matches signatures that appear only in a successful SSRF response — /etc/passwd (root:x:0:0), AWS metadata markers (ami-id, instance-id, security-credentials), STS credential JSON (AccessKeyId / SecretAccessKey), GCP computeMetadata output, and leaked process-env dumps. A redirect the server followed to an internal host is treated as vulnerable; a leaked internal-connection error (ECONNREFUSED / EHOSTUNREACH / timeout, or an internal IP echoed back) is downgraded to a warning; a DNS-rebinding vector that times out is treated as safe. Nandix never exploits or extracts data — it only sends requests and reads the response.

Why it's dangerous

SSRF is one of the highest-impact web vulnerabilities because it turns your own server into an entry point. The most common target is the cloud metadata service (AWS, GCP, Azure) at 169.254.169.254, which can hand back temporary IAM credentials — effectively the keys to your cloud account. Beyond that, attackers use SSRF to map and reach internal services never meant to face the internet, read local files via file://, and pivot deeper into your network. It's serious enough that OWASP added SSRF as its own category in the Top 10.

Example finding

The endpoint fetched http://169.254.169.254/ and returned instance metadata — an attacker could retrieve temporary IAM credentials for your cloud account.

How to fix it

Defend in layers — no single check is enough. Allowlist destinations: only permit requests to domains you explicitly approve, rather than trying to block bad ones. Block internal ranges: reject loopback, RFC 1918 private ranges, and link-local/metadata addresses (169.254.0.0/16) — after resolving the hostname, so an attacker can't hide an internal IP behind DNS. Restrict schemes to http/https only; reject file://, gopher://, dict://. Don't follow redirects blindly — re-validate the destination after each hop.

js

import dns from 'node:dns/promises';
import ipaddr from 'ipaddr.js';

async function assertSafeUrl(raw) {
  const url = new URL(raw);
  if (!['http:', 'https:'].includes(url.protocol)) throw new Error('scheme blocked');
  const { address } = await dns.lookup(url.hostname);
  const range = ipaddr.parse(address).range();
  if (['private', 'loopback', 'linkLocal', 'uniqueLocal'].includes(range))
    throw new Error('internal address blocked');
  return url;
}

Severities & standards

Severities

CRITICAL · HIGH

References

• OWASP A10:2021 — Server-Side Request Forgery (SSRF)
• OWASP SSRF Prevention Cheat Sheet

Frequently asked questions