Glossary

SSRF

Why every feature that fetches a URL someone else typed needs a guard in front of it.

By Roger Campos · Last updated: September 2026

TL;DR

Server-side request forgery (SSRF) is an attack where someone makes a server fetch a URL of their choosing, so that the request comes from inside the server's network. Attackers use it to reach internal services, admin panels and cloud metadata endpoints that are unreachable from the internet.

Start free See the API

Free plan, no credit card. 1,000 credits a month.

How it works

Link previews, webhooks, PDF renderers, screenshot services, importers: any feature that takes a URL and fetches it. If the server fetches whatever it is given, an attacker gives it http://169.254.169.254/ — the cloud metadata address, which can hand out credentials — or http://localhost:6379, or an admin panel on a private address. The request comes from inside the firewall, so it gets in. SSRF is its own category in the OWASP Top 10.

Blocklisting obvious strings does not hold. 127.0.0.1 can be written as 2130706433, 0x7f.0.0.1 or 127.1; a public hostname can resolve to a private address (DNS rebinding); a public URL can redirect to an internal one.

In practice

Defences that hold

Parse and normalise the URL the way the fetcher will, then decide on the normalised host.
Refuse IP literals, internal hostnames and non-default ports unless you need them.
Check the address the connection actually reached, not just the one the name resolved to earlier.
Apply the same rules to every URL you fetch — including webhook URLs you deliver to.
Run the fetcher on a network that has nothing internal to reach.

URLpipe

How URLpipe guards against it

URLpipe is a URL fetcher, so these rules sit in front of every request. A URL must be public http(s) on the default port, with a real domain name: no IP address in any notation, no localhost or internal suffix like .internal or .local, no credentials before the host. The host is normalised first — IDNA, percent-escapes, trailing dots — so the check sees what the browser will. The rendering engine then refuses a page whose server turns out to be at a private address, and webhook URLs pass the same checks.

The trade-off is yours to know: URLpipe cannot fetch http://203.0.113.5/ or https://example.com:8443/. Give it a hostname on the standard port.

Try it

Server-side request forgery (SSRF), on a page you choose

Get the rendered HTML of any URL

Paste a link and get the page's HTML after JavaScript has run and redirects have been followed — the DOM a real browser sees, not the empty shell curl returns.

Try it free

FAQ

Frequently asked questions

Why is SSRF dangerous in the cloud?

Because cloud servers can reach a metadata endpoint that returns instance credentials. An SSRF that reaches it can turn a URL field into access to the cloud account.

Is blocking private IP ranges enough?

Only if you check the address the request actually connected to. Checking the string, or resolving the name once and fetching later, leaves room for alternative notations, DNS rebinding and redirects.

Why can't URLpipe fetch an IP address or a custom port?

Refusing them is part of its SSRF defence. Use the site's hostname on the standard port.

Keep reading

Fetch a page from a residential address Failed requests are never charged Cookie banners and ads in scraped pages Verify a webhook signature in Node.js Rendered HTML API Residential proxy All of glossary

See it on your own pages.

Free plan, no card. Confirm your email and your API key is live — you'll be making real requests in minutes.

Start free Email the team