Build fluency in the vocabulary of preventing a user-supplied URL from tricking a server into an unintended request.
0 / 5 completed
1 / 5
At standup, a dev mentions an attacker supplying a URL to a feature like a link-preview tool, tricking the server itself into making a request to an internal resource the attacker could never reach directly. What is this vulnerability called?
Server-Side Request Forgery, or SSRF, is when an attacker supplies a URL to a feature like a link-preview tool, tricking the server itself into making a request to an internal resource the attacker could never reach directly from outside the network. Cross-site scripting instead runs a malicious script in a victim's own browser, which is a fundamentally different attack surface. This server-initiated request is what makes SSRF dangerous, since the server often has network access to internal resources an external attacker doesn't.
2 / 5
During a design review, the team wants a URL-fetching feature to only ever request a destination from a pre-approved set of hosts, rather than fetching whatever URL a user happens to supply. Which capability supports this?
Destination allowlisting restricts a server-initiated fetch to a pre-approved set of hosts, so a user-supplied URL pointing anywhere else is rejected before the server ever makes the request. Fetching any URL a user supplies directly, with no restriction, lets an attacker point the server at an internal resource it was never meant to reach. This allowlisting is one of the most direct ways to close off the SSRF attack surface for a feature that legitimately needs to fetch a user-specified URL.
3 / 5
In a code review, a dev notices code explicitly rejecting a request whose resolved destination falls within a private or link-local IP range, like the address commonly used for a cloud provider's metadata service, before making the actual fetch. What does this represent?
Blocking a private or link-local destination IP range before making a server-initiated fetch stops a request from reaching a sensitive internal target, like a cloud provider's metadata endpoint, even if a destination allowlist was somehow bypassed. Making the fetch first and checking the range only afterward is too late, since the request, and any resulting data leak, has already happened. This upfront range check is an important second layer of defense specifically against reaching an internal or cloud-metadata address.
4 / 5
An incident report shows an attacker used a URL-preview feature to point the server at the cloud provider's internal metadata endpoint and successfully retrieved sensitive temporary credentials, because the feature fetched whatever URL was supplied with no destination restriction at all. What practice would prevent this?
Validating and restricting the fetch destination, including explicitly blocking a private or metadata IP range, before the server makes a user-supplied request prevents exactly the kind of internal reach that let credentials leak in this incident. Continuing to fetch whatever URL is supplied, with no validation at all, leaves that same path open to any attacker who discovers the feature. This destination validation is a mandatory control for any feature that makes a server-side request based on user input.
5 / 5
During a PR review, a teammate asks why the team validates and restricts a fetch destination server-side instead of trusting that a user would never intentionally supply a malicious internal URL. What is the reasoning?
A malicious user can deliberately supply a URL pointing at an internal resource the server can reach but the user themselves never could directly, which is exactly the leverage an SSRF attack exploits. The server itself must validate the destination rather than trusting user input, since the user's intent can't be assumed to be benign. The tradeoff is the added maintenance of keeping a destination allowlist, or an IP-range blocklist, accurate as the application's legitimate needs evolve over time.