Server-Side Request Forgery (SSRF)
Some features take a URL from the user and have the server fetch it: import from a link, generate a preview, call a webhook. If the app will fetch any URL it is given, the attacker borrows the server's position on the network to reach places the attacker cannot reach directly. This exercise explains why that is powerful and how to constrain it.
Log in or create a free account to submit keys and track your progress.
What you will learn
- Explain how a URL-fetching feature lets an attacker use the server as a proxy
- Understand why internal services and cloud metadata are the prize
- Recognise SSRF-prone features and code
- Explain the defence: allowlist destinations, block internal ranges, harden the metadata service
Before you start
These exercises cover what this one builds on.
In this exercise
- A feature that fetches a URL
- Borrowing the server's position
- Recognising it
- The fix: control the destination
🔒
This is a Pro exercise
Pro unlocks every exercise, the written solutions, the video walkthroughs and badge certificates. Free exercises stay free.
See Pro plans Create a free account4 sections · 2 keys · 50 points