Malware
Server-side request forgery
Also called SSRF.
Server-side request forgery is a flaw that lets an attacker make your server fetch a URL of their choosing. The server sits inside your network, so it can reach places the attacker cannot.
How it is measured
Find features that fetch a URL for the user: image import, webhook test, PDF renderer, link preview, OAuth metadata. Submit a URL that points to a server you control and see whether a request arrives, from which IP, and with what headers.
Then try internal targets in a safe test: localhost, private ranges, and the cloud metadata address 169.254.169.254. A different response, a time difference, or returned content shows the server reached them. Blind SSRF only shows in timing or out-of-band callbacks.
Worked example
A form builder has an 'import logo from URL' box. A tester enters http://169.254.169.254/latest/meta-data/iam/security-credentials/ and the preview returns a role name. A second request for that role returns temporary AWS keys valid for six hours.
The fix has layers: block private and link-local ranges after DNS resolution, require IMDSv2 on the instance, and give the role only the S3 access the app needs. Without the third step, a leaked key still reaches every bucket in the account.
How it differs
Remote code execution runs attacker code on your server. SSRF only makes the server send a request, but that request can reach internal services, cloud credentials, and admin panels, and sometimes leads to RCE. An open redirect sends the visitor's browser elsewhere; SSRF sends your server.
Common errors
Filtering with a blocklist of hostnames and missing 127.1 or decimal IP forms. Validating the URL and then following redirects to a different place. Checking the name before DNS resolves, so a rebinding host passes. Assuming internal-only services need no authentication. Forgetting that the blind version leaves no response to read.
In practice
List every feature where your server fetches a user-supplied URL. Resolve the host, reject private, loopback, and link-local addresses, do not follow redirects blindly, and filter egress from the app servers. On cloud, enforce IMDSv2 and use least-privilege instance roles.