What Is Server-Side Request Forgery (SSRF) and How Do You Prevent It?

Your application needs to fetch a URL. It pulls an image from a link, checks a webhook, renders a preview, or calls an internal service. A user hands it an address, and your server makes the request on the user’s behalf. Server-side request forgery begins the moment an attacker controls where your server points. The server holds trust inside your network. The attacker borrows it. One crafted URL reaches systems the attacker should never touch, and your own code delivers the data back.

Server-side request forgery, shortened to SSRF, tricks your server into sending a request to a destination an attacker picks. The flaw sits in features built to be helpful. Your application accepts a URL or a hostname, then fetches it. When you skip validation, the attacker swaps a legitimate address for an internal one. The request now travels from inside your trusted network, past firewalls built to stop outside traffic. The Canadian Centre for Cyber Security points software vendors toward secure design and development as the baseline for closing flaws like this one, in its joint guidance on a software security code of practice. SSRF lives in how your code handles a request, not in the network around it.

How server-side request forgery works

Picture a feature built to import a profile picture from a web address. A user pastes a link, and your server downloads the image. An attacker pastes a different link. Instead of a picture, the address points at an internal admin panel, a database on a private subnet, or a cloud metadata service. Your server, trusted inside the network, fetches the target and returns the response. The attacker reads internal pages, maps your private systems, and pulls secrets no outside request would ever reach. In cloud setups, the prize sits at a fixed internal address. The metadata service at 169.254.169.254 hands out temporary credentials to anything on the host. An SSRF request to this address steals the keys to your cloud account.

The Canadian cost of one unchecked request

SSRF is not theory. The 2019 Capital One breach ran on it. An attacker sent a forged request to the AWS metadata service, lifted cloud credentials, and copied data on roughly 100 million people. Around six million Canadians sat inside the stolen records, which pushed the Office of the Privacy Commissioner of Canada to open an investigation. One web application flaw exposed social insurance numbers, bank account details, and credit histories across the country. The attack needed no malware and no stolen password. It needed one input field where the server trusted a user-supplied URL.

What makes an application open to SSRF

Three conditions set up every SSRF attack. First, your application takes a URL, hostname, or IP address from user input. Second, your server makes a request to the supplied destination. Third, your code never checks the destination against a list of approved targets. Remove the third condition and the attack stops. Most defences work by refusing to send any request your application did not plan to send. You decide the destinations in advance. The user supplies data, never the address.

How you prevent server-side request forgery

You close SSRF by controlling the destination, not the input. Build an allowlist of the exact hosts and IP addresses your feature needs, and reject everything else with an exact, case-sensitive match. Do not accept a full URL from a user. Take the piece you need, such as an image ID, then build the request in your own code with a fixed scheme, port, and path. Turn off redirect following in your HTTP client, so a validated address never redirects to an internal one. The OWASP Server-Side Request Forgery Prevention Cheat Sheet lays out this pattern and the supporting controls in full.

Layer network controls under the code. Put your fetching service on a segment with no route to internal admin systems or databases, so a forged request hits a wall. Block the cloud metadata address and private IP ranges at the network edge. On AWS, move to IMDSv2 and switch off IMDSv1, which closes the exact path the Capital One attacker walked. Validate the resolved IP address, not only the hostname, to defeat DNS rebinding tricks. Reference the CCCS Baseline Cyber Security Controls for small and medium organizations when you set these network rules, since they map to the segmentation and access controls SSRF defence needs.

Build the team who designs these flaws out

Scanners catch some SSRF holes. Trained developers stop writing them. The Certified Secure Web Application Engineer path teaches developers to handle user-supplied URLs with allowlists and locked-down request logic from the first line of code. The Certified Web Security Engineer track widens the skill across the full application stack. On the offensive side, the Certified Professional Ethical Hacker program shows your testers how attackers chain SSRF to reach cloud credentials and internal systems. The Certified Penetration Testing Engineer path drives this testing deeper, with hands-on labs against live web targets. Mile2 ties each course to a working role, so your people apply the skill the week they finish.

Server-side request forgery survives because applications keep trusting a destination a user controls. The fix sits within reach. Define the destinations your features need, reject every address outside the list, cut off redirects, and lock down the network path and cloud metadata. Then put trained developers and testers on the work so the flaw never ships. The Capital One breach proved how far one forged request travels. Attackers probe Canadian applications daily for the next input field left open. Close it first, and their forged request reaches nothing.