How Server-Side Request Forgery (SSRF) Works and Fixes

Written by Ruben Selby, founder and penetration tester at Wolfcore. Last reviewed 8 November 2026.

In one sentence: SSRF is when an attacker tricks your web application into making a request on their behalf, so they can reach systems that are hidden from the internet but trust your server.

Part of our Hacking techniques library.

What it is

Many applications fetch things from an address: a product picture, a webhook, a link preview, a stock check. If the address comes from the user and the application does not check it, the user decides where your server goes.

PortSwigger’s Web Security Academy defines SSRF as a vulnerability that lets an attacker cause the server-side application to make requests to an unintended location. OWASP puts it in its Top 10 as A10:2021 and describes it as the application fetching a remote resource without validating the user-supplied URL, even when a firewall, VPN or access control list is in place.

How it works

The application has a feature that fetches an address. The address, or part of it, comes from a request the user controls.
The attacker changes the address. Instead of the intended service, they point the application at somewhere it can reach but they cannot.
The server makes the request. It sends it from inside your network, using its own identity and trust.
The response, or its effect, comes back. PortSwigger describes two common targets: the server itself, where a request from the local machine skips access controls, and other back-end systems on private addresses that often have weaker security because the network layout was meant to protect them.
The attacker pivots. OWASP lists scenarios: mapping internal ports, reading local files or internal services, and reading cloud metadata services, which hold credentials for the machine.

Some cases are “blind”: the application makes the request but does not show the response. PortSwigger says blind SSRF is harder to exploit but can sometimes lead to remote code execution. Hidden entry points include partial URLs, data formats such as XML that can include URLs, and analytics software that visits the address in a Referer header.

A harmless illustration of the code pattern

Vulnerable: the server fetches whatever address the user sends.

def stock_check(request):
    address = request.form["address"]
    return http_get(address)

Safer: the user picks a name, and the server looks up the address it already trusts.

STOCK_SERVICES = {"london": "https://stock.internal.example/london"}

def stock_check(request):
    target = STOCK_SERVICES.get(request.form["store"])
    if target is None:
        return reject()
    return http_get(target, follow_redirects=False)

Who it affects and how badly

Sole trader to 10 staff (small online shops): custom plug-ins or scripts that fetch URLs can expose it. Worst case: a stolen cloud key and a bill, or exposed customer data.
10 to 50 staff (SaaS start-ups, recruitment platforms, estate agent portals): features like “import from URL”, webhooks and PDF generators are common. Worst case: access to internal admin tools and the customer database, lost clients and a reportable breach.
50 to 250 and 250 plus (fintech, insurance, telecoms, councils): many internal services that trust each other. Worst case: one flaw leads to wide data exposure and regulator questions.

The risk is similar in the UK, EU, US and Armenia. What changes is who you must tell and who can fine you.

Real examples

Capital One, 2019. The US Department of Justice press release says the intrusion happened through a misconfigured web application firewall that gave access to the data, and that a GitHub user alerted Capital One on 17 July 2019. A secondary source, Security.org, reports that the attacker used server-side request forgery to extract temporary credentials from AWS’s metadata service, which opened access to many storage buckets. The same page reports an $80 million OCC fine and a $190 million class action settlement. Note that the DOJ page itself does not use the term SSRF.

What we check on a test

This is method, not a list of findings.

Every feature that accepts a URL, hostname or file: webhooks, avatar and logo imports, link previews, PDF and screenshot tools, XML and file imports.
Whether the application can reach internal addresses, localhost or cloud metadata, and whether it returns the response.
Whether redirects are followed, and whether allow-lists check the final destination.
Whether the server’s outbound firewall is deny-by-default.
Whether cloud metadata is protected, for example with IMDSv2 on AWS, and what the server’s role can access if its credentials leak.

The UK angle

The ICO’s guide to data security says the UK GDPR requires you to test and evaluate your security measures regularly, with penetration testing as an example, to document the results and act on them, and that the ICO considers your technical and organisational measures when deciding on an administrative fine. An SSRF flaw in a customer-facing app that holds personal data is exactly what that testing is meant to find.

How the attack path looks

Worked example (an illustration, not a real client)

A 15-person SaaS start-up lets customers “import a logo from a web address”. The feature runs on a cloud server with a broad role. A tester, or an attacker, finds that the feature will fetch addresses inside the start-up’s own network. Credentials for the cloud role can leak, and with them the storage holding customer files. The cost is a forced credential rotation, an urgent customer notice, a personal data breach assessment and lost trust with a bigger client. The fix is to let the user upload the file, or to fetch only from a short allow-list, and to restrict the server’s role.

How to detect it

Log outbound requests made by your application servers, and review requests to internal ranges, localhost or metadata addresses. OWASP recommends logging all accepted and blocked network flows on firewalls.
Alert on application servers reaching systems they never normally contact.
Check cloud audit logs for unusual use of a server’s role credentials from outside the server.
Review any feature that takes a URL as part of code review.

How to fix or prevent it

Do not accept full URLs from users. Let them choose from a list and build the request yourself, as in the safer pattern above (OWASP).
Enforce the scheme, port and destination with a positive allow-list. OWASP says not to rely on deny-lists or regular expressions, because they can be bypassed.
Disable HTTP redirects in the client that makes the request.
Do not send raw responses back to the user.
Use deny-by-default firewall rules so the server can only reach what it needs, and segment the network.
On AWS, move to IMDSv2 and disable IMDSv1, and give the server’s role only the permissions it needs.
Test every URL-taking feature before release.

Frequently asked questions

What is the difference between SSRF and CSRF? SSRF makes a server send a request. CSRF makes a user’s browser send one.

Does a firewall stop SSRF? Not alone. OWASP says SSRF can reach systems protected by firewalls and access lists because the request comes from the trusted server.

Why is SSRF dangerous in the cloud? OWASP lists cloud metadata services as a common target, because they can hold credentials for the machine.

Back to the Hacking techniques hub.

Sources

How Wolfcore helps

A Wolfcore penetration test finds this the way an attacker would, by hand, not with a scanner. Start with the free web vulnerability scan at https://wolfcore.co.uk/free-web-vulnerability-scan/ and read about web application testing at https://wolfcore.co.uk/services/web-application-penetration-testing/.

How server-side request forgery (SSRF) works and how to stop it