SSRF
Server-Side Request Forgery
0 / 4 solved
Abuse legitimate server-side URL fetchers to reach destinations users cannot access directly.
Quick reference
SSRF cheat sheet
Find features where the server fetches a URL on the user's behalf, then determine which destinations and redirect paths it can reach.
Where to look
- URL previewers, webhook testers, image/avatar imports, PDF renderers, feed readers, document fetchers, proxy endpoints, and callback verification.
- Any parameter named url, uri, endpoint, webhook, callback, image, feed, link, source, or import is worth reviewing.
- Watch for server responses that contain fetched titles, status codes, image dimensions, or remote content.
Simple checks
- First prove the server is making the request using a harmless controlled URL in the lab.
- Use clues the application already exposes: recent webhook history, connected-service names, error messages, or documented redirectors.
- If there is a hostname allowlist, test redirects and destination normalization rather than inventing random hostnames.
http://127.0.0.1:8080/healthhttp://169.254.169.254/latest/meta-data/https://go.fetchlab.test/forward?to=http://reports.internal/daily/exportRealistic tips
- Parse URLs and validate exact normalized hostnames/IPs. A string merely containing 127.0.0.1 must not count as localhost.
- Validate resolved IPs and repeat destination checks after every redirect.
- Block private, loopback, link-local, and other sensitive networks unless explicitly required, and enforce outbound network segmentation.