| name | ssrf-detection |
| description | Detect Server-Side Request Forgery vulnerabilities in web applications and APIs |
| domain | web-security |
| subdomain | ssrf |
| tags | ["web","ssrf","server-side","request-forgery"] |
| version | 1.0.0 |
| author | BerkahKarya |
| license | MIT |
SSRF Detection
When to use
Apply this skill when testing endpoints that accept URLs or hostnames as input (e.g., webhooks, image processors, PDF generators, import features).
Detection steps
- Identify URL parameters: Look for parameters like
url=, host=, target=, image_url=, webhook_url=, callback=.
- Test with external endpoint: Submit a URL pointing to a collaborator (e.g., Burp Collaborator, webhook.site) and verify the server makes an outbound request.
- Test internal targets: If external requests succeed, try internal addresses:
http://127.0.0.1/ — localhost
http://169.254.169.254/latest/meta-data/ — AWS metadata
http://localhost:8080/ — common internal services
- Check protocol schemes: Test
file:///etc/passwd, gopher://, dict:// if HTTP is accepted.
- Bypass filters: If simple internal URLs are blocked, try:
- DNS rebinding
- URL encoding (
http://127.0.0.1 → http://2130706433)
- Alternate localhost representations (
0.0.0.0, [::1])
Common payloads
http://169.254.169.254/latest/meta-data/iam/security-credentials/ — AWS creds
http://127.0.0.1:6379/ — Redis
file:///etc/passwd — local file read
False positive indicators
- The server resolves the URL but doesn't fetch it (DNS lookup only)
- The application validates the URL against an allowlist
- The response shows a generic error without making any outbound request
Reporting
Include the collaborator interaction log or the internal service response as evidence.