Server-side request forgery: how to prevent SSRF attacks

What Is Server-Side Request Forgery (SSRF)?

Server-side request forgery is a web application vulnerability in which an attacker causes a server to send a request to an unintended destination. The destination may be an internal service, the same server, a cloud metadata endpoint, or an attacker-controlled external host.

Applications create SSRF exposure when they accept a URL for features such as importing an image, checking stock, generating a preview, delivering a webhook, or reading a remote document. The server then performs the network request, often from a more trusted network location than the user.

OWASP describes SSRF as abuse of server functionality to read or update internal resources. Its examples include cloud metadata services, internal REST interfaces, HTTP database interfaces, and local files. Treat the URL as untrusted data even when the feature itself is legitimate.

For background on the request protocol involved, see ArtHack’s explanation of application programming interfaces (APIs). An API is a defined way for software systems to exchange requests and responses, and an internal API may trust calls that come from the application’s network.

How Does SSRF Work?

SSRF works when user input reaches a server-side HTTP client without sufficient destination controls. The application resolves the supplied address, opens a connection, sends a request, and may return the response to the attacker.

A vulnerable endpoint might accept a parameter like image_url or stock_api. In simplified Python, the dangerous pattern looks like this:

import requests

url = request.args["url"]
response = requests.get(url, timeout=5)
return response.text

The timeout limits how long the operation waits, but it does not prevent SSRF. An attacker may submit a loopback address such as http://127.0.0.1:8080/admin, a private address such as http://10.0.0.5/, or a cloud metadata address.

What Does an SSRF Example Scenario Look Like?

Imagine a store application that receives a stock API URL from the browser. A normal request might contain:

POST /product/stock
Content-Type: application/x-www-form-urlencoded

stockApi=https%3A%2F%2Fstock.example.test%2Fcheck%3FproductId%3D6

The server fetches the URL and displays the stock result. If the application accepts an altered value such as http://localhost/admin, the server may access an administrative endpoint that is not exposed to ordinary users.

The same weakness can reach another back-end system. For example, http://192.168.0.68/admin may resolve from the application server even though it is unreachable from the public internet. If the internal service relies on network location instead of authentication, the impact can include unauthorized reads or state changes.

PortSwigger’s SSRF Web Security Academy material documents both local-server and back-end SSRF scenarios. Use deliberately vulnerable labs for security practice, never production systems or infrastructure you do not own.

What Are Standard, Blind, and Time-Based Blind SSRF?

Standard SSRF returns some or all of the destination response to the attacker. This makes the flaw easier to confirm because the response body, status code, or headers may reveal the target’s behavior.

Blind SSRF sends the request but does not expose the response. You can still detect it through a controlled callback service, application logs, DNS logs, or a measurable side effect. A webhook tester under your control can confirm that the server made an outbound connection.

Time-based blind SSRF relies on response timing. A reachable service, a refused connection, and a filtered network path may produce different delays. Timing alone is weak evidence, so confirm findings with logs or a controlled endpoint.

What Is the Impact of an SSRF Attack?

An SSRF attack can turn a public feature into a network pivot. The server may reach resources protected from the internet, use service credentials, or send authenticated requests that the attacker could not create directly.

• Data exposure: responses may reveal internal configuration, credentials, API keys, or sensitive records.
• Unauthorized actions: an internal service may accept requests to create users, change settings, trigger jobs, or modify data.
• Cloud credential theft: a vulnerable workload may reach a cloud metadata service and expose temporary credentials if metadata access is not restricted.
• Network discovery: response codes and timing can reveal which internal hosts and ports are reachable.
• Further compromise: stolen credentials or access to an internal administrative interface can enable attacks beyond the original application.

SSRF does not guarantee command execution or credential disclosure. The result depends on outbound network access, destination authentication, cloud configuration, response handling, and the permissions assigned to the application.

What Are Common SSRF Attack Targets and Scenarios?

The most exposed features are those that fetch, publish, parse, or preview remote content on behalf of a user. Review these paths during design and code audits:

• URL imports: avatar downloads, remote image loaders, document importers, and feed readers.
• Webhooks: integrations that let an administrator or user enter a callback URL.
• Media processing: thumbnail generators, screenshot services, video fetchers, and PDF converters.
• Link previews: social cards and metadata extractors that request a page before displaying it.
• Internal APIs: stock, payment, search, monitoring, or deployment services reachable from the application network.
• Cloud metadata: provider-specific endpoints that expose workload identity or instance information.
• Protocol handlers: file, gopher, ftp, and other schemes supported unintentionally by a network library.

A WordPress plugin can create similar exposure if it passes an administrator-supplied URL to a remote request function without validating the destination. Review plugin code that uses functions such as wp_remote_get(), and apply the same controls to custom themes, integrations, and scheduled jobs.

How Do You Find and Test for SSRF Vulnerabilities?

Find SSRF by tracing every user-controlled value that reaches a network request, then test it only in an authorized staging environment. Search source code for HTTP client calls and inspect the complete request flow, including redirects, DNS resolution, proxy behavior, and response handling.

Useful code searches include requests.get, fetch(), curl_exec, wp_remote_get, Java’s HttpClient, and Node.js libraries such as axios. Dynamic testing should use a controlled domain that records DNS and HTTP requests, rather than probing third-party hosts.

Test whether the application rejects loopback, private, link-local, and reserved addresses after DNS resolution. Also check whether it follows redirects, accepts alternate IP formats, permits unexpected schemes, or validates only the hostname text before a resolver returns a different address.

Where Is the Hidden SSRF Attack Surface?

Hidden SSRF attack surface appears in features that do not look like network tools to the user. A “save image from URL” button, an RSS importer, a URL-based health check, and an outbound notification can all make server-side requests.

Inspect asynchronous workers and background queues as well as web controllers. A request may be validated at the front end, stored in a database, and fetched later by a worker with broader network access.

• Review file uploads that accept remote URLs as an alternative to local files.
• Trace administrator-only settings because authenticated users can still be compromised or have excessive privileges.
• Check integrations that construct URLs from multiple fields, such as host, port, and path.
• Inspect error messages and logs for destination URLs, response bodies, and resolver results.

How Do Partial URLs, Data Formats, and HTTP Headers Create Risk?

Partial URLs create risk when an application adds a trusted prefix to attacker-controlled text. Code such as base_url + user_path can be unsafe if the input changes parsing, escapes the intended path, or introduces a different authority component.

Data formats can hide URLs inside JSON, XML, form fields, image metadata, or imported documents. Search nested values recursively and validate the final URL after parsing, not only the first visible string.

HTTP headers can also expose secondary attack paths. An application that fetches the URL in a Referer, Origin, or custom integration header may become vulnerable if a downstream component treats that value as a destination.

Use a standards-compliant URL parser and compare the parsed scheme, hostname, port, and path. Do not implement security checks with a regular expression that only searches for strings such as localhost.

How Do Attackers Bypass SSRF Defenses?

Attackers bypass weak SSRF defenses when validation checks a different representation from the one used by the network client. Parsing, DNS resolution, redirects, proxy settings, and IP encoding must follow one consistent policy.

How Do Blacklist-Based Filters Fail?

Blacklist-based filters block known strings such as localhost, 127.0.0.1, or /admin, but they do not describe every unsafe destination. Alternate loopback representations, DNS rebinding, encoded characters, IPv6 forms, and redirects can defeat incomplete lists.

Do not rely on removing suspicious substrings. Parse the URL, resolve its hostname, reject every resulting private or reserved address, and repeat the check after redirects if redirects are allowed at all.

How Do Whitelist-Based Filters Fail?

Whitelists are stronger when they contain exact hosts and paths, but a loose match can still be bypassed. A check for trusted.example may incorrectly accept trusted.example.attacker.test or a URL whose user-information field makes the text look trusted.

Compare canonical parsed values, not raw input. Store approved destinations as configuration identifiers where possible, then map an identifier such as stock_service to a fixed origin on the server.

How Do Open Redirects and URL Parsing Differences Matter?

An open redirect can turn an allowed public URL into a route toward an internal target if the server follows redirects. ArtHack’s explanation of HTTP redirections and their configuration covers the status-code behavior that developers must account for.

Different libraries may parse unusual URLs differently, especially around backslashes, encoded characters, ports, credentials, and IPv6 brackets. Use one maintained parser, reject user information in URLs, disable automatic redirects by default, and test the exact library used in production.

How Do You Prevent SSRF Attacks?

Effective SSRF prevention combines application validation with network controls. No single input filter can compensate for unrestricted outbound access and overprivileged service identities.

How Should You Validate and Allowlist Destinations?

Allow only the destinations that the feature genuinely needs. Prefer a server-side identifier over a user-supplied URL, for example:

ALLOWED_ORIGINS = {
    "stock_service": "https://stock.example.test/api/check"
}

origin = request.json["service"]
if origin not in ALLOWED_ORIGINS:
    raise ValueError("Unsupported destination")

If arbitrary external URLs are required, validate the scheme, hostname, resolved addresses, port, and path before connecting. Resolve DNS yourself, reject loopback, private, link-local, multicast, and unspecified addresses, and protect against a change between validation and connection where your HTTP stack allows it.

Which URL Schemes, Ports, and Redirects Should You Restrict?

Permit only https unless the feature has a documented reason to support another scheme. Block file, gopher, ftp, and custom schemes unless they are explicitly required and separately secured.

Allow only the ports required by the integration, commonly 443 for HTTPS. Disable automatic redirects, or validate every redirect destination against the same policy and cap the redirect count at a small number such as 3.

Set connection and response limits, including a short connect timeout, a total request timeout, maximum response bytes, and a restricted method such as GET when the feature does not need writes.

How Should You Secure Cloud Metadata and Internal Services?

Do not expose cloud metadata services to application code unless the workload requires them. Use your provider’s hardened metadata mode where available, restrict metadata access at the host or workload layer, and assign short-lived identities with only the permissions the process needs.

Require authentication and authorization on internal APIs instead of trusting source IP addresses. Separate administrative interfaces from application networks, remove unused HTTP database interfaces, and log rejected as well as successful outbound requests.

Transport encryption protects data in transit but does not decide whether a destination is safe. ArtHack’s article on Transport Layer Security (TLS) explains why certificate validation must remain enabled, while SSRF controls still need to validate where the connection goes.

How Do Network Segmentation and Least Privilege Reduce SSRF Risk?

Network segmentation limits the systems a compromised application can reach. Place outbound traffic behind an egress firewall or proxy with explicit destination rules, and deny access to management networks, metadata endpoints, databases, and internal control planes by default.

Least privilege means giving each process only the network routes, credentials, filesystem access, and cloud permissions it needs. Run URL-fetching workers separately from sensitive application services, and use a dedicated identity with no administrative permissions.

What Belongs on an SSRF Prevention Checklist?

Use this checklist during design reviews, code reviews, penetration tests, and incident response. Recheck controls after changing HTTP libraries, proxies, cloud platforms, or network routes.

• Inventory every feature that fetches or publishes a URL from user, administrator, database, file, or header input.
• Replace arbitrary URLs with fixed destination identifiers wherever the product allows it.
• Parse URLs with a maintained library and validate scheme, hostname, port, path, and credentials.
• Resolve hostnames and reject loopback, private, link-local, multicast, unspecified, and reserved addresses.
• Disable redirects or validate every redirect destination with the same policy.
• Permit only required methods, schemes, ports, response sizes, and request durations.
• Block cloud metadata and sensitive internal networks at the network layer.
• Require authentication on internal services and avoid trust based only on source location.
• Assign minimal cloud, network, filesystem, and application permissions to the fetching process.
• Log destination, resolved address, port, result, redirect chain, and rejection reason without recording secrets.
• Test standard, blind, and time-based behavior in an authorized staging environment using controlled callback infrastructure.
• Review SSRF defenses whenever application or dependency versions change. Guidance and vendor behavior were checked in August 2026, but implementation details and cloud controls should be re-verified against current documentation.