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.
What does the "Server-Side Request Forgery Vocabulary" vocabulary exercise cover?
This exercise tests real IT vocabulary related to server-side request forgery vocabulary through 5 multiple-choice questions, each built from realistic workplace sentences rather than abstract definitions.
Is this vocabulary exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is completely free — no account, sign-up, or payment required.
How many questions does this exercise have?
This exercise has 5 questions. Each one shows a real-world sentence or scenario with multiple-choice options and an explanation once you answer.
What happens after I answer a question?
You'll see immediate feedback showing whether your answer was correct, along with a short explanation of why — then a button to move to the next question, and a full results screen at the end.
Can I retry the exercise if I get questions wrong?
Yes. Once you reach the results screen, click "Try again" to reset your answers and go through the exercise from the start as many times as you like.
Do I need to create an account to take this exercise?
No account is needed. Your answers are scored in your browser during the session — nothing is saved to a server, so you can jump straight in.
Is my progress saved if I leave the page?
No — progress within an exercise resets if you navigate away or reload. Each exercise is short enough to complete in a few minutes in one sitting.
Are these vocabulary exercises connected to other topics?
Yes — browse the full vocabulary exercises hub to find related modules covering adjacent IT topics and roles.
How is this different from reading a glossary or blog article?
Exercises like this one are active recall drills — you have to choose the correct term or phrasing yourself, which builds retention faster than passively reading a definition.
Where can I find more vocabulary exercises?
Browse the full Vocabulary exercises hub for hundreds of modules covering Agile, DevOps, security, databases, architecture, and more — organised by IT role and skill.