How to Prevent SSRF Attacks in 2025

Server-Side Request Forgery (SSRF) is a web vulnerability that lets an attacker trick your server into making HTTP requests to unintended locations. In an SSRF attack, a malicious user finds a way to supply or alter a URL that your backend will fetch. This can allow them to access internal services (like databases, cloud metadata endpoints, etc.) or even send requests to external systems as if they were from your server. The result? Potential exposure of sensitive data like internal files, cloud credentials, or the ability to perform actions inside your network that the attacker should never be able to do.

Why SSRF Is Dangerous

SSRF vulnerabilities have gained infamy due to their severe impact, especially in cloud environments. A notorious example is the Capital One breach – the attacker exploited an SSRF in a web application firewall to access AWS’s internal metadata service and retrieve cloud credentials. Using those credentials, they accessed over 100 million customer records stored in S3. In essence, SSRF turned the vulnerable server into a proxy that bounced the attacker’s requests into a protected network. Modern architectures often trust internal traffic, so an SSRF can bypass many defenses by originating calls from “inside” your system. This is why OWASP added SSRF to its Top 10 list and why cloud providers regularly patch SSRF issues (e.g., Azure fixed four SSRF vulnerabilities in just one month of 2023).

Some real-world impacts of SSRF attacks include:

• Reading internal files or APIs: An attacker can often fetch URLs like http://localhost/admin or internal API endpoints not exposed publicly. This might leak admin pages or data not meant for external eyes.

  
  

• Scanning or attacking internal network: The server can be misused to scan ports or attack internal services, since the server might have access that outsiders lack.

  
  

• Cloud metadata exploitation: In cloud hosts, accessing http://169.254.169.254/latest/meta-data (the AWS/Azure/GCP instance metadata address) via SSRF can reveal credentials or keys, leading to full cloud account takeover.

  
  

• Potential Remote Code Execution: In some cases, SSRF can lead to running unauthorized commands. For example, an SSRF that targets an internal API could trigger actions or if the server interprets response data in an unsafe way, it might even execute code.

Example: How SSRF Works

Imagine a web app that lets users enter a URL to preview content (perhaps a “fetch URL” feature or an image loader). The code might look like this (in Python for example):

python
CopyEdit

url = request.values.get('image_url')  
response = requests.get(url)  
return HttpResponse(response.content)

If the app blindly fetches whatever URL a user provides, an attacker can input

http://localhost/secure-data or http://10.0.0.5:3306/

etc., forcing the server to request internal addresses. A classic SSRF trick on cloud servers is to input

http://169.254.169.254/latest/meta-data/iam/security-credentials/

– this URL returns AWS instance credentials if not blocked. The server will fetch it, and the attacker gains those credentials! Essentially, the attacker abuses your server’s ability to make HTTP calls.

How to Prevent SSRF

1. Allowlist domains/IPs: The most effective defense is to strictly limit what locations your server can fetch. If your application needs to call internal APIs or specific external sites, build an allowlist of hostnames or IP ranges. Reject any URL not on the list. For example, only allow *.yourcompany.com or specific API endpoints. This ensures an attacker can’t point to random internal addresses. Be cautious with DNS – resolve the hostname and check it doesn’t hop to an unapproved IP (no sneaky DNS rebinding).

2. Validate and sanitize user input: If users provide URLs, validate the scheme and format.

Only allow http or https(no file:// or gopher:// schemes

which have been used to smuggle requests). Use your programming language’s URL parser to break apart the input and ensure it’s well-formed and not pointing to localhost or private IPs. Regex alone is brittle

(e.g. 127.0.0.1 can be encoded as 2130706433)

Instead, resolve the hostname and check the IP is not a private range. Also, disable redirects or at least don’t follow redirects to disallowed domains – attackers could use an open redirect to bypass filters.

3. Use platform security features: Cloud providers learned from the Capital One incident – for example, AWS released IMDSv2 (Instance Metadata Service version 2) which requires a session token and is not exploitable via simple SSRF. Ensure you’ve enabled such features (e.g., require metadata tokens) so even if SSRF occurs, the blast radius is limited. Similarly, firewall off internal services from the webserver where possible.

4. Least privilege for network access: Consider running risky code in a network-isolated environment. If a component of your app doesn’t need outbound internet or access to internal subnets, block its egress. That way, an SSRF in that component can’t reach sensitive endpoints. Some organizations deploy egress filters or use container network policies to restrict addresses that can be contacted.

5. Monitoring and alerts: It’s wise to monitor internal services for unusual requests or monitor your server for abnormal outbound calls. SSRF attacks might trigger weird domain lookups or access internal hosts at odd hours. Detecting those can help you respond quickly.

Developer Tip: Always ask, “Does this feature really need to fetch arbitrary URLs?” Often, providing such flexibility isn’t worth the security risk. If you must, prefer server-side curated fetches (e.g., the server has a preset list of safe resources to fetch based on a user’s choice, rather than accepting a raw URL).

Ghost’s Solution for SSRF

Preventing SSRF is partly about good coding and partly about diligent testing. This is where Ghost Security can help in a big way. Ghost’s AI-driven code analysis can trace how user input flows into network calls. For example, Ghost will flag if a request to an external URL is constructed with user-provided data without proper validation. It’s like having a smart code reviewer that knows all the SSRF tricks — including obscure bypasses — looking over your shoulder. By scanning your application’s code (you can scan one repo for free with Ghost), you would be able to easily detect usage of

requests.get(user_url)

or a near infinite set of logically similar variations before they ever reach production.

Ghost's detection capability also identifies if your code defenses (like allowlists or regex filters) could be bypassed. The platform understands context – it knows the difference between fetching a constant internal URL versus one derived from user input. This context-aware analysis means fewer false alarms and only the user-exploitable SSRF risks are brought to your attention.

Try it out: If you’re curious whether your code is vulnerable to SSRF or other logic flaws, you can scan your repository for free with Ghost. It will provide a detailed report of any findings, including SSRF, with line-of-code pinpointing and remediation guidance. That way, you not only learn about the issue but also how to fix it (for instance, Ghost might suggest adding an allowlist check around that risky code snippet).

By combining secure coding practices (input validation, allowlists, etc.) with Ghost’s automated scanning, you’ll significantly reduce the chance that an SSRF will slip through. SSRF may be a serious threat, but with the right precautions and tools, you can keep your servers fetching only what they should – and nothing more.