Server-Side Request Forgery
Server-Side Request Forgery, or SSRF, happens when attacker-controlled input makes a server send a request. The request reaches a place it should not reach.
Another example
An invoice tool accepts a supplier logo URL. It parses once, allows only approved supplier HTTPS hosts, and rejects resolved private, loopback, link-local, or metadata addresses. It also turns off redirects, limits bytes and time, uses an egress proxy, and blocks `http://169.254.169.254`.
Main parts
- 01Attacker-influenced URL
- 02Server-side fetch capability
- 03Destination and egress controls
Use it when
Review the threat for every server feature that fetches a user-influenced URL. Enforce destination allowlists, network exit limits, and checks after name lookup.
Do not use it when
A text prefix, one DNS lookup, or URL parsing alone is not enough. Redirects and DNS rebinding can cross the checked boundary.
Name used in code
strict URL parser + destination allowlist + IP-range checks + redirect policy + egress proxy Before you ship
Work only within an explicitly authorized and isolated defense test. Check the trust boundary, inert regression case, mitigation, and handling of secrets and personal data. Check redacted detection signals, safe failure, incident owner, recovery, and rollback. Never test a real target.
Outcome: Assess and mitigate the risk from Server-Side Request Forgery. Do not implement, enable, or use the attack. User context: An invoice tool accepts a supplier logo URL. It parses once, allows only approved supplier HTTPS hosts, and rejects resolved private, loopback, link-local, or metadata addresses. It also turns off redirects, limits bytes and time, uses an egress proxy, and blocks `http://169.254.169.254`. Risk or control to address: Server-Side Request Forgery. Why it applies: Review the threat for every server feature that fetches a user-influenced URL. Enforce destination allowlists, network exit limits, and checks after name lookup. Classification boundary: A text prefix, one DNS lookup, or URL parsing alone is not enough. Redirects and DNS rebinding can cross the checked boundary. Safety requirements: Test only in an isolated space with explicit permission. Use inert, harmless inputs. Protect secrets and personal data. Name the trust boundary and record the mitigation. Operational safeguards: Set up detection and logs that hide sensitive data. Name the incident owner. Define a safe failure mode and rollback before release. Acceptance criteria: A defensive regression test fails before the mitigation and passes after it. No real target, secret, or personal data is used. Monitoring and rollback are verified. Evidence and limits (evidence boundary): It is official for that source. Other platforms or teams may use the term in another way. Unknowns to confirm: Authorized scope, affected assets, data class, threat actor, incident owner, and rollback limits.
Check this request
Review the current use of Server-Side Request Forgery. Definition: Server-Side Request Forgery, or SSRF, happens when attacker-controlled input makes a server send a request. The request reaches a place it should not reach. Release checks: Work only within an explicitly authorized and isolated defense test. Check the trust boundary, inert regression case, mitigation, and handling of secrets and personal data. Check redacted detection signals, safe failure, incident owner, recovery, and rollback. Never test a real target. Before changing code, report the evidence you found, gaps, severity, and the smallest safe fix.