TL;DR
SSRF (Server-Side Request Forgery) tricks your server into making requests to places it shouldn't. If your app fetches URLs provided by users, attackers can make it fetch internal resources like http://localhost/admin or cloud metadata endpoints. Prevent it by validating and allowlisting URLs before fetching them.
The Simple Explanation
You have a feature that imports images from URLs. A user gives you a URL, your server fetches it. An attacker provides http://169.254.169.254/latest/meta-data/ (AWS metadata endpoint). Your server fetches it and returns cloud credentials. The server, sitting inside your network, can access things the attacker cannot directly reach.
Common SSRF Scenarios
- Image import: "Provide a URL to import"
- Webhooks: "Send notifications to this URL"
- URL preview: "Fetch title and image from link"
- PDF generation: "Render this URL as PDF"
- Proxy features: "Fetch URL through our service"
What Attackers Target
- Cloud metadata: 169.254.169.254 (AWS, GCP, Azure)
- Internal services: localhost, 127.0.0.1, internal hostnames
- Private networks: 10.x.x.x, 192.168.x.x, 172.16.x.x
- Admin interfaces: Internal dashboards, databases
Prevention
function isUrlAllowed(url) { const parsed = new URL(url);
// Only allow HTTPS if (parsed.protocol !== 'https:') return false;
// Block private IPs and localhost const ip = await resolveHostname(parsed.hostname); if (isPrivateIP(ip) || isLoopback(ip)) return false;
// Optional: allowlist specific domains const allowed = 'example.com', 'trusted-cdn.com'; if (!allowed.some(d => parsed.hostname.endsWith(d))) return false;
return true; }
DNS rebinding warning: Attackers can make a domain resolve to a public IP initially, then change to an internal IP. Validate the resolved IP, not just the hostname. Resolve the hostname yourself and check before fetching.
What can attackers do with SSRF?
SSRF lets attackers access internal services not exposed to the internet, read cloud metadata endpoints (AWS 169.254.169.254), scan internal networks, bypass firewalls, and potentially execute code on internal systems. In cloud environments, metadata endpoints can expose credentials.
How do I prevent SSRF?
Use allowlists for permitted domains and IP ranges. Block requests to private IP ranges and localhost. Do not trust user input for URLs. Use a URL parser to validate the destination before making requests. Consider using a proxy service that validates destinations.
Where does SSRF commonly occur?
SSRF commonly occurs in features that fetch URLs: webhooks, image/file imports from URLs, PDF generators that render URLs, RSS feed readers, and any feature that takes a URL as input and fetches its content on the server side.