CWE-918.
SSRF appeared as A10 in the OWASP Top 10:2021. In the
OWASP Top 10:2025,
CWE-918 is mapped under A01: Broken Access Control.
What Is SSRF (Server-Side Request Forgery)?
In practical terms, SSRF is a destination-control vulnerability. It becomes possible when attacker-influenced data determines where a server-side component sends a request without sufficiently restricting the final destination.
Features that legitimately make outbound requests can include image importers, URL preview services, webhook validators, document renderers, callback handlers, proxy features, and APIs that retrieve data from another service. These features are not vulnerable simply because they make network requests; the weakness appears when untrusted input can influence more of the request destination than the application intended.
That control may involve the URL, hostname, protocol, port, path, redirect target, or resolved network address. If the application does not enforce an effective destination policy, the server can be used as an unintended request proxy.
SSRF is therefore best understood as a trust-boundary problem: the attacker influences the destination, while the server may possess network reach, identity, or access that the attacker does not have directly.
| Element | Role in SSRF |
|---|---|
| Attacker-controlled input | Influences a URL, hostname, callback, resource location, or another request destination |
| Server-side request capability | Fetches or connects to the destination on behalf of the application |
| Broader server reach | May include localhost, private networks, backend services, internal APIs, or cloud-only resources |
| Missing destination control | Allows the request to leave the feature’s intended trust boundary |
SSRF belongs to the broader family of
cyber security vulnerabilities.
What distinguishes SSRF is that attacker-controlled data influences a request made from the server-side environment, potentially giving that request access to destinations unavailable to a normal external client.
How Does SSRF Work?
At a high level, SSRF follows a simple data flow: attacker-controlled input influences where a server-side component sends a request, the server contacts an unintended destination, and the request produces either a response or an observable side effect.
- Attacker-controlled input:
The application accepts a URL, hostname, callback address, resource location, or another value that the user can influence. - Server makes the request:
The application processes that input and initiates an outbound request from the server-side environment using an HTTP client, URL fetcher, document renderer, integration service, or similar component. - The request reaches an unintended destination:
If destination controls are insufficient, the server may contact localhost, a private API, a cloud metadata service, or another destination outside the feature’s intended trust boundary. - A response or side effect occurs:
The application may return data from the destination, trigger an action, or reveal indirect evidence such as a timing difference, log entry, DNS request, or HTTP callback. In blind SSRF, the response body may not be returned to the requester at all.
A more detailed way to understand the same flow is:
| Stage | What Happens | Typical Examples |
|---|---|---|
| Attacker-controlled input | A user influences a URL, hostname, callback, or other request destination. | Image URL, webhook target, import URL, link preview, API parameter |
| Server-side request | The application processes the input and initiates an outbound request from the server environment. | HTTP client, URL fetcher, document renderer, integration service |
| Unintended destination | The request reaches a destination outside the feature’s intended destination policy or trust boundary. | Localhost, private API, cloud metadata service, arbitrary external host |
| Response or side effect | The destination returns data or the request causes an observable effect. | Returned response, status or timing difference, DNS/HTTP callback, state change |
The key relationship is:
attacker controls destination → server possesses broader network reach → server sends the request → a trust boundary is crossed.
This is why SSRF can reach resources that are unavailable to a normal external client. The vulnerability does not disable a firewall or automatically compromise the server. Instead, it abuses a request path the server is already allowed to use.
Why Do SSRF Vulnerabilities Occur?
SSRF usually Occur when an application legitimately needs to fetch a remote resource but its destination controls do not match the business requirement. Several implementation problems can create that gap.
- Arbitrary user-controlled URLs: the application accepts a complete destination URL when only a small, known set of services is actually required.
- Weak destination validation: validation checks the string superficially instead of enforcing a canonical destination policy.
- Unsafe redirect handling: the first URL is permitted, but the HTTP client follows a redirect to a destination that was never validated.
- Inconsistent URL parsing: validation code and the networking library interpret the same URL differently.
- Overly broad protocol support: a generic URL library may accept schemes the application never intended to use.
- Excessive server network access: the request-capable service can reach sensitive subnets, management interfaces, or metadata endpoints without a business need.
- Implicit internal trust: backend services rely on network location instead of strong authentication and authorization.
Input validation matters, but input validation alone is not an SSRF defense. Effective prevention also constrains where the request-capable service can connect and limits what happens if application-layer validation fails.
What Can an SSRF Attack Target?
The impact of SSRF is determined largely by the destinations the vulnerable server can reach. Thinking in terms of target classes is more useful than treating every SSRF finding as equivalent.
The Vulnerable Server Itself
A server may expose administrative, monitoring, debugging, or management interfaces only on its loopback interface. Those services are invisible to remote clients but still reachable from processes running on the host. SSRF can become significant when the vulnerable application can request those local-only endpoints and the services assume local traffic is trusted.
Internal Services and APIs
Application servers often communicate with private APIs, microservices, internal dashboards, service registries, and other backend systems on non-public networks. Those services may have weaker authentication because network isolation was expected to provide part of the security boundary. SSRF can expose that assumption by sending requests from an already trusted network position.
This is especially relevant to API-heavy architectures. ScanTitan’s guide to API security testing explains why API security requires testing not only public endpoints but also authentication, authorization, data flows, and backend trust relationships.
Cloud Metadata Services
Cloud platforms provide metadata services so workloads can retrieve instance information and, depending on the platform and configuration, identity-related data needed by applications. Because these services are intentionally reachable from the workload itself, an SSRF path inside a cloud-hosted application can create a route toward metadata that an external client could not query directly.
The exact protections differ by provider. AWS supports session-oriented IMDSv2 and can require token use; Azure’s Instance Metadata Service requires a Metadata: true header and rejects requests containing X-Forwarded-For; Google Cloud documents metadata access controls and recommends limiting which processes can reach the metadata server.
Cloud metadata should therefore be treated as one layer in a broader cloud-security model rather than as a universal SSRF exploit target. ScanTitan’s guide to cloud security scanning covers the wider configuration, identity, workload, and exposure context.
External Services
SSRF is not limited to internal destinations. A vulnerable server may also be induced to contact arbitrary external hosts. This can expose the organization’s IP address as the apparent source of the traffic, trigger unintended third-party requests, or turn the server into a limited request proxy. The practical impact depends on the request method, headers, body, protocols, and response handling the application allows.
Visual opportunity: SSRF target map
Show the vulnerable application in the center with four destination classes around it: localhost, private/internal service, cloud metadata service, and external service. The purpose is to show that SSRF impact is determined by server reachability, not by one fixed target.
Types of SSRF
The most useful distinction is whether the application exposes the result of the server-side request directly. Avoid treating every detection behavior as a separate vulnerability class.
Standard or Non-Blind SSRF
In standard SSRF, the application returns the fetched response or enough of it for the requester to observe what the destination returned. This makes the data flow easier to verify because the server-side request and its response are visible in the application’s normal behavior.
Blind SSRF
Blind SSRF occurs when attacker-controlled input still causes the server to make a request, but the response body is not returned to the requester. The flaw can still matter because the request itself may create a side effect or reveal reachability through indirect evidence.
Security teams may confirm blind SSRF through authorized out-of-band observations such as controlled DNS or HTTP callbacks, request logs, timing differences, or other server-side telemetry. These are detection patterns for blind SSRF rather than universally separate SSRF types.
SSRF Example
Consider an application that generates previews for documents hosted at a user-supplied URL. A legitimate request might look conceptually like this:
GET /preview?url=https://cdn.example.com/manual.pdfThe application receives the URL, fetches the document from the server side, and returns a preview. The feature becomes vulnerable if the user can replace the expected public destination with an unintended internal destination and the application fetches it without an effective destination policy.
GET /preview?url=http://internal-service.example/private-resourceThe security issue is not the syntax of that request. It is that the application accepts a destination outside the feature’s intended trust boundary and then reaches it from the server’s network position.
A secure design would avoid accepting arbitrary destinations when possible. If only a known content service is required, the application should select from approved destinations server-side rather than trusting a client-supplied URL.
Why Is SSRF Especially Important in APIs and Cloud Environments?
Modern applications contain more server-to-server communication than a traditional monolithic website. REST and GraphQL APIs call internal services, webhook systems connect to customer endpoints, document processors retrieve remote assets, service meshes route between microservices, and cloud workloads query provider services. Each legitimate outbound request path is a place where destination control matters.
APIs are especially relevant because they often accept structured data containing URLs, callbacks, import locations, avatar links, webhook destinations, or integration settings. An endpoint may appear to expose only one public API while the server behind it can reach a much larger private service graph. That is why SSRF can become an API trust-boundary vulnerability, not merely a bad URL-validation bug.
For teams assessing API exposure, API vulnerability scanning can help exercise runtime endpoints and identify request-handling weaknesses, while deeper business-logic and trust-boundary questions may require manual review.
Cloud environments add another dimension: workloads often have identity, network, and metadata relationships that do not exist for an anonymous internet client. The security objective is therefore not just to stop one URL pattern. It is to ensure that a request-capable workload has only the network reach and cloud permissions it actually needs. Common configuration weaknesses that increase blast radius are covered in ScanTitan’s guide to cloud misconfigurations.
What Is the Impact of SSRF?
SSRF severity varies widely. A low-impact instance may only cause the server to fetch a harmless external URL, while a more serious flaw can expose sensitive internal capabilities. The impact depends on reachable destinations, authentication, server privileges, response visibility, supported protocols, request methods, and whether the vulnerability can be chained with other weaknesses.
| Potential Outcome | When It Can Occur |
|---|---|
| Internal data exposure | The server can reach a private service and the application returns or otherwise exposes the response |
| Unauthorized internal actions | A reachable backend accepts requests based on network location or weak internal authentication |
| Service enumeration | Different responses, timing, or side effects reveal which internal destinations are reachable |
| Cloud identity exposure | The vulnerable workload can reach metadata or identity-related services and provider-specific safeguards are insufficient |
| Denial of service | The request function can be abused to consume resources or repeatedly contact expensive or unstable destinations |
| Support for lateral movement | SSRF exposes or interacts with internal systems that enable a larger attack chain |
| Remote code execution | Possible in some chains when SSRF reaches another vulnerable or dangerous internal service; SSRF does not inherently provide RCE |
SSRF does not automatically mean full server compromise
A finding should be evaluated by the destinations the server can reach, what those destinations expose, whether the response is observable, and what privileges are involved. RCE is a possible chained outcome in some environments, not the definition of SSRF.
How Is SSRF Detected?
Reliable SSRF detection combines runtime testing, code analysis, and network evidence. No single technique sees every request path, especially when requests happen asynchronously or the response is not returned to the user.
| Detection Method | What It Can Reveal | Important Limitation |
|---|---|---|
| DAST | Runtime features where user-controlled input influences a request destination and the behavior is observable | Coverage depends on crawling, authentication, API discovery, request correlation, and reachable application states |
| Out-of-band application security testing (OAST) | Blind SSRF where a unique controlled DNS or HTTP interaction proves the server initiated a request | Confirms interaction but may not establish the full reachable internal impact |
| SAST / code analysis | Data flows where untrusted URL or host input reaches network-request APIs | Static analysis may not model runtime validation, redirects, DNS behavior, or environment-specific reachability perfectly |
| Manual review and testing | Business-logic request paths, partial URL control, redirect behavior, custom parsers, and environment-specific trust boundaries | Requires skilled review and explicit authorization |
| Outbound network monitoring | Unexpected connections from application workloads to internal, metadata, or unusual external destinations | Detects behavior after or during execution; it does not by itself identify the vulnerable input path |
| Application and request logs | Correlate user input, URL-fetch activity, redirect chains, destination resolution, and backend errors | Only useful when the relevant events are logged with enough context |
Blind SSRF is where out-of-band evidence becomes particularly useful. A server may perform the request successfully while returning only a generic success or error message to the client. In an authorized test, a unique controlled callback can prove that the server initiated an outbound interaction without requiring the backend response body to be exposed.
Detection should also distinguish request capability from security impact. Confirming that the server contacts a controlled external destination demonstrates server-side request behavior; determining whether the application can reach sensitive internal resources requires additional context about destination controls and network segmentation.
How to Prevent SSRF
SSRF prevention works best as defense in depth. The strongest design reduces how much destination choice the client controls, validates destinations consistently, restricts server network reach, hardens cloud metadata access, and monitors the outbound requests that remain necessary. OWASP’s SSRF Prevention Cheat Sheet similarly separates cases where a strict allowlist is possible from cases where the application genuinely needs to contact arbitrary external destinations.
1. Avoid Arbitrary User-Controlled Destinations Where Possible
The safest URL is often one the user never supplies. If a feature only needs to contact three partner APIs, store those destinations server-side and let the client select a logical identifier rather than submit an unrestricted URL.
2. Use Strict Allowlists When the Business Flow Has Known Destinations
When the application only needs to communicate with identified services, enforce a narrow allowlist of expected schemes, hostnames, ports, and paths as appropriate. Validate the parsed destination, not merely whether the original string contains an approved word.
3. Parse and Normalize URLs Consistently
Use a well-maintained URL parser and make security decisions on the same canonical representation that the network client will use. Avoid ad-hoc string parsing because URL syntax includes user-info fields, fragments, encoded characters, IPv6 forms, internationalized hostnames, and other structures that different parsers may interpret differently.
4. Restrict Protocols and Schemes
If the feature only requires HTTPS, do not permit arbitrary URL schemes. Generic networking libraries may support local-file access or non-HTTP protocols that the application never intended to expose. Protocol restrictions reduce the number of interpreters and destination types that must be secured.
5. Control Redirects and Revalidate Every Destination
A permitted URL can redirect to a prohibited destination. Disable automatic redirect following when the feature does not require it. If redirects are necessary, apply the same destination policy to each redirect target before the next request is sent.
6. Validate Hostnames, DNS Resolution, and IP Ranges
Where arbitrary external destinations must be supported, destination validation should consider both the hostname and the addresses it resolves to. Requests should not unexpectedly resolve into loopback, private, link-local, or otherwise prohibited address spaces. DNS answers can change, so the application and network architecture should not rely on one early string check as the only control.
7. Use Network Segmentation and Egress Filtering
The request-capable workload should only be able to reach the networks and services required for its role. Segmentation and deny-by-default egress policy reduce the blast radius if application-layer validation is bypassed. A URL-fetching worker, for example, usually should not have unrestricted access to management networks simply because it needs outbound HTTPS.
8. Apply Least Privilege to Backend Services and Workload Identity
Internal services should still authenticate and authorize requests instead of treating source network location as sufficient proof of trust. Cloud roles, service accounts, managed identities, and backend credentials should expose only the permissions the workload needs.
9. Harden Cloud Metadata Access
Use provider-specific metadata protections and disable metadata access where it is unnecessary. On AWS, require IMDSv2 where compatible and consider endpoint/hop-limit controls; on Azure, use local firewall controls when only specific processes need IMDS; on Google Cloud, isolate processes that should not be able to query metadata. Metadata hardening reduces one important SSRF target but does not replace application and network defenses.
10. Log and Monitor Server-Side Requests
Log enough context to investigate unusual outbound activity: the application feature, normalized destination, resolved address, redirect behavior, response status, and request correlation identifier where appropriate. Network monitoring can then flag unusual access from public-facing workloads to sensitive internal ranges or metadata services.
Visual opportunity: layered SSRF defenses
Show the sequence: reduce user destination control → canonical URL parsing → allowlist/destination policy → redirect validation → DNS/IP checks → egress filtering → metadata hardening → monitoring. The diagram should make clear that no single validation rule carries the entire defense.
Why Blacklists Alone Are Weak SSRF Defenses
A blacklist tries to identify destinations that look dangerous and reject them. That model is fragile because URLs and network destinations can be represented in multiple valid ways, DNS answers can change, allowed pages can redirect elsewhere, and different libraries can disagree about how a URL should be parsed.
The core problem is semantic: a blacklist asks “does this string contain something we recognize as bad?” while the security requirement is “is the final network destination permitted for this feature?”
| Weak Control | Why It Can Fail | Stronger Direction |
|---|---|---|
| Block specific hostname strings | Equivalent destinations can have different representations | Parse, normalize, resolve, and enforce a destination policy |
| Validate only the first URL | Redirects can change the final destination | Disable unnecessary redirects or revalidate every hop |
| Trust one DNS lookup | DNS answers may change between validation and connection | Design validation and network controls to account for DNS behavior |
| Use a regex as a URL parser | The HTTP client may interpret ambiguous syntax differently | Use a standards-aware parser consistently |
This is why prevention should prefer explicit allowlists when destinations are known and combine application controls with network restrictions when arbitrary external access is a real business requirement.
SSRF vs CSRF: What Is the Difference?
SSRF and cross-site request forgery (CSRF) both involve an attacker influencing a request, but the request originates from a different security principal and abuses a different trust relationship.
| Question | SSRF | CSRF |
|---|---|---|
| Who sends the sensitive request? | The server-side application | The victim’s browser |
| Primary trust abused | Server/network/service trust | User/session trust |
| Typical destination | Local services, private APIs, cloud metadata, backend or external systems | An application action the authenticated victim is authorized to perform |
| Requires a logged-in victim? | Usually no | Typically depends on the browser carrying credentials or equivalent ambient authority |
| Core defenses | Destination restrictions, URL parsing, redirect controls, network segmentation, egress filtering, least privilege | Anti-CSRF tokens, SameSite cookies, and origin/request validation where appropriate |
In short, SSRF makes the server send an unintended request; CSRF makes the user’s browser send an unintended authenticated request. The similar names describe different vulnerability classes and should not be used interchangeably.
Can Vulnerability Scanners Detect SSRF?
Automated scanners can detect some SSRF vulnerabilities, but coverage depends heavily on how the application exposes server-side request behavior.
DAST can test running web applications and APIs for inputs that influence outbound destinations. When the fetched response is visible, confirmation may be relatively direct. For blind SSRF, a scanner may need a unique out-of-band DNS or HTTP interaction so it can correlate a callback with the exact tested input.
Static analysis can complement runtime scanning by identifying untrusted URL or host values that reach network-request functions in source code. It may also find request paths hidden behind application states that a crawler never reaches. However, static tools do not automatically know whether a destination is reachable in production or whether runtime network policy blocks the request.
Business-logic SSRF can still require human review. Partial control over a URL, custom redirect behavior, multi-step integrations, asynchronous workers, and environment-specific network trust may be difficult to prove with one automated technique. This is one reason vulnerability scanning and penetration testing remain complementary rather than interchangeable.
ScanTitan’s website vulnerability scanner uses DAST to test web applications and APIs for runtime weaknesses including SSRF. API-specific coverage can also be evaluated through API vulnerability scanning, but no automated scanner should be presented as capable of finding every SSRF path.
Frequently Asked Questions
What does SSRF stand for?
SSRF stands for Server-Side Request Forgery. It describes a vulnerability where attacker-controlled input causes a server-side application to make a network request to an unintended destination.
Is SSRF a server-side vulnerability?
Yes. The defining request is generated from the server-side environment rather than the attacker’s browser. That distinction is what lets SSRF potentially reach localhost, private networks, internal APIs, or cloud services available to the server.
What is blind SSRF?
Blind SSRF occurs when the server makes the attacker-influenced request but the backend response body is not returned to the requester. Detection may rely on controlled out-of-band callbacks, timing, logs, or other side effects.
Can SSRF lead to remote code execution?
It can in some attack chains, but SSRF does not inherently provide remote code execution. RCE requires an additional condition, such as a reachable internal service that exposes dangerous functionality or another vulnerability that can be chained with SSRF.
Why is SSRF dangerous in cloud environments?
Cloud workloads often have access to metadata, managed identities, private services, and internal APIs that external clients cannot reach. SSRF can become more serious when a vulnerable workload has broad network reach or excessive cloud permissions, which is why metadata hardening and least privilege matter.
What is the difference between SSRF and CSRF?
SSRF causes a server-side application to make an unintended request, while CSRF causes a victim’s browser to send an unintended request using the victim’s existing session or credentials. SSRF abuses server/network trust; CSRF abuses user/session trust.
Can a vulnerability scanner detect SSRF?
Yes, some SSRF vulnerabilities can be detected by DAST, especially when the request destination is controllable and the result is observable. Blind SSRF may require out-of-band callback correlation, while complex business-logic paths can require code review or manual testing.
How can SSRF be prevented?
Prevent SSRF by minimizing user control over request destinations, using strict allowlists where possible, parsing URLs consistently, restricting schemes and redirects, validating resolved destinations, applying egress filtering and segmentation, hardening cloud metadata access, and running backend services with least privilege.
