What is SSRF?
Your app has a feature that fetches a URL — maybe it generates link previews, imports data from a webhook, or downloads an image from a user-provided address. An attacker swaps that URL for http://169.254.169.254/latest/meta-data/ and suddenly your server is fetching its own cloud credentials and handing them back.
The core problem is trust. Your server has network access that the outside world doesn't — internal APIs, databases, cloud metadata services. When it blindly fetches a URL that a user controls, it becomes a proxy into your private infrastructure.
SSRF became serious enough that OWASP gave it a dedicated category in the 2021 Top 10. The Capital One breach in 2019, which exposed over 100 million records, started with an SSRF vulnerability that reached the AWS metadata service.
How does SSRF work?
An SSRF bug needs two ingredients: a server-side function that makes HTTP requests, and user input that controls the destination URL without proper validation.
Here's a typical vulnerable API route that fetches a URL to generate a preview:
// app/api/preview/route.ts
export async function POST(req) {
const { url } = await req.json();
// Problem: fetches whatever URL the user provides,
// including internal services and cloud metadata.
const response = await fetch(url);
const data = await response.text();
return Response.json({ preview: data });
}// app/api/preview/route.ts
import { isAllowedUrl } from '@/lib/url-validator';
export async function POST(req) {
const { url } = await req.json();
// Validate: must be HTTPS, public IP, allowed domain
if (!isAllowedUrl(url)) {
return Response.json(
{ error: "URL not allowed" },
{ status: 400 },
);
}
const response = await fetch(url, {
redirect: 'error', // block redirects to internal IPs
signal: AbortSignal.timeout(5000),
});
return Response.json({ preview: await response.text() });
}Why do AI tools generate SSRF vulnerabilities?
When you ask an AI to build a feature that fetches external URLs — link previews, webhook handlers, image importers — it generates code that works. The fetch call succeeds, the data comes back, the feature is complete. What it skips is the part where you check whether that URL should be fetched at all.
- Fetching URLs looks like normal functionality. There's nothing suspicious about a fetch() call. The AI doesn't distinguish between fetching a public website and fetching an internal metadata endpoint — it's the same function.
- Internal network topology is invisible to the model. The AI has no concept of your cloud environment, your VPC layout, or which IP ranges are internal. It can't protect against something it doesn't know exists.
- URL validation is boring plumbing. Building a proper URL allowlist with DNS resolution checks, IP range blocking, and redirect handling is tedious. AI tools optimize for the feature, not the guardrails around it.
SSRF is especially dangerous in cloud environments. A single unvalidated fetch can reach the AWS metadata service (169.254.169.254), the GCP metadata service, or any internal microservice — turning a simple URL fetch into a full infrastructure compromise.
Common SSRF patterns
Link preview generators
User pastes a URL, server fetches it to extract title and image — classic SSRF entry point.
Webhook URL configuration
User sets a callback URL that the server will POST to later. Attacker points it at an internal service.
Image/file import from URL
"Import from URL" features that download remote files without checking the destination.
PDF/screenshot rendering
Server-side HTML-to-PDF or screenshot tools that load user-controlled URLs with full network access.
How Flowpatrol detects SSRF
Flowpatrol probes your app's URL-fetching features the same way an attacker would — by supplying internal and metadata URLs to see what comes back:
- 1Finds URL input points by crawling forms, API endpoints, and request parameters that accept URLs.
- 2Tests internal targets — sends requests pointing to localhost, cloud metadata IPs, and common internal service addresses.
- 3Checks for data leakage by analyzing whether the response contains internal data, error messages, or metadata that should never be exposed.
- 4Validates redirect handling — tests whether your app follows redirects from a public URL to an internal one, a common SSRF bypass technique.
SSRF is hard to catch with static analysis because the vulnerability depends on runtime behavior and network context. Flowpatrol tests it live, against your running app.
Related terms
Check your app for SSRF.
Flowpatrol tests your URL-fetching endpoints against internal targets and cloud metadata services. Paste your URL and find out.
Try it free