Security explainer

SSRF starts with a helpful URL box

The feature says "paste a URL and we will fetch it for you." The attacker hears "make our server talk to places your browser cannot reach."

~6 minSecurity
scroll
01 · the feature

Fetching a URL moves trust to your server

URL importers are useful: unfurl a link, fetch an avatar, import a feed, preview a webhook. But once your backend makes the request, it has a different network position than the user. It may reach internal hosts, metadata services, admin panels, or private IP ranges.

preview-url.js

This helper is one validation step away from becoming a tunnel.

controls quiet

Security gets real when the trust boundaries light up. Poke it and see what has to hold.

02 · the move

The URL can point inward

The attacker does not need your credentials if they can make your server ask the question. They try localhost, private address ranges, cloud metadata endpoints, redirects, DNS tricks, and alternate URL forms. The server becomes the browser they wanted.

zsh · attacker input

Do not fetch first and validate later.

03 · the defense

Validate, resolve, and restrict the egress path

A strong defense is layered: allow only expected schemes, parse with a real URL parser, resolve DNS, block private and link-local ranges, re-check after redirects, limit response size and timeout, and send fetches through an egress proxy that enforces the policy.

security control lab
exposed
hardened0
exposed: the feature trusts too much and records too little

Flip the switches and watch the story turn into a tiny operating model.

0schemes usually enough: http and https
0egress policy beats scattered checks
0trust in user-provided hostnames
04 · the habit

Treat server-side fetch as a privileged action

The mindset shift is the whole game. A URL box is not just input validation. It is a network access decision. Put it through the same review you would give a new outbound integration.

source trail