On this page
What Is SSRF (Server-Side Request Forgery)?
SSRF tricks your server into fetching an attacker-chosen URL, exposing internal services. Learn how it works, why AI code introduces it, and defenses.
Quick answer
- SSRF makes your server fetch a URL the attacker chooses, turning the server into a proxy into your internal network.
- It’s especially dangerous in the cloud, where internal metadata endpoints can leak credentials.
- Defenses are allow-lists, blocking private addresses, and not fetching arbitrary user URLs.
What is SSRF?
Server-side request forgery is a vulnerability that lets an attacker cause the server to make requests to unintended destinations. When an application fetches a URL supplied by a user — a preview thumbnail, a webhook, an image import — and doesn’t validate it, the attacker can redirect that fetch to internal services, localhost, or cloud metadata endpoints that should never be reachable. It’s A10 in the OWASP Top 10.
How it works
Consider an endpoint that fetches a URL to generate a preview:
@app.get("/preview")
def preview(url: str):
return fetch(url) # no validationAn attacker requests url=http://169.254.169.254/latest/meta-data/iam/security-credentials/. On AWS, that address is the instance metadata service, and the response can contain the role’s temporary credentials. The server, fetching on the attacker’s behalf, hands over the keys.
Why AI-generated code is prone to it
Independent testing has found that AI coding tools consistently introduce SSRF when building URL-fetching features — the “fetch whatever URL the user gives us” pattern is the natural, simplest implementation. The vulnerability requires an extra validation step that looks unnecessary in a demo, which is precisely why it ships.
How to prevent it
Validate and constrain every server-side fetch: use an allow-list of permitted hosts where possible, block private and loopback addresses (and re-resolve DNS to prevent bypasses), and never follow user-controlled redirects into internal ranges. For cloud apps, also restrict access to the metadata endpoint where the platform allows it.
Where this bites vibecoders
The pattern is specific and recurring: a feature that “fetches a URL” — previews, imports, webhooks — built by an assistant as a raw fetch. In a cloud environment, that single endpoint can expose your instance’s credentials. The habit is to treat any user-supplied URL as an attack, and to route server-side fetches through an egress proxy or allow-list by default.
Where AI coding assistants get this wrong
- Fetching arbitrary user URLs with no host validation.
- Failing to block
localhost, private ranges, and cloud metadata IPs. - Following redirects without re-validating the destination.
- Using the server’s full credentials for the outbound fetch.
Checklist
- Allow-list permitted hosts wherever possible.
- Block private, loopback, and metadata addresses on outbound fetches.
- Re-resolve DNS and re-check the IP before connecting.
- Run outbound fetches through a constrained egress proxy.
- Restrict cloud metadata service access where available.
FAQ
What is the difference between SSRF and CSRF?
CSRF tricks a user’s browser into making a request to your site. SSRF tricks your server into making a request to another system. CSRF targets the victim’s session; SSRF targets your backend’s network position. See What Is CSRF?.
Why is the metadata endpoint so dangerous?
Cloud metadata endpoints (like AWS’s 169.254.169.254) expose the instance’s identity and, often, temporary credentials. An SSRF that reaches it can steal the role’s credentials and pivot into the cloud account — turning one request into full account access.
Is blocking private IPs enough?
It’s necessary but not always sufficient, because attackers use DNS rebinding and redirects to bypass naive IP checks. Pair IP blocking with allow-lists and DNS re-resolution for a robust defense.