Server-Side Request Forgery (SSRF) is a web application security vulnerability that allows an attacker to influence requests made by a server. Instead of directly connecting to a protected service, the attacker abuses a server-side feature to make the request on their behalf.
SSRF becomes particularly interesting when a vulnerable application can communicate with systems that ordinary internet users cannot reach. These may include internal APIs, cloud metadata services, localhost applications, management interfaces, databases, or other services inside a private network. OWASP describes SSRF as an attack that abuses application functionality to interact with internal or external network resources.
Modern applications make SSRF especially relevant. URL preview features, webhook integrations, document importers, image fetchers, cloud services, microservices, and API integrations all create situations where a backend server may need to retrieve a resource on behalf of a user.
The security problem begins when the application trusts the destination supplied by the user without sufficiently verifying where the server is actually connecting.
What Is Server-Side Request Forgery (SSRF)?
Server-Side Request Forgery is a vulnerability where an attacker manipulates a server into sending a request to an unintended destination.
The important word is server-side.
In a normal request, a user connects directly to a public service:
User → Internet → Web ApplicationWith SSRF, the application becomes the middleman:
Attacker
↓
Web Application
↓
Internal / External ResourceThe attacker may not have direct network access to the final destination. The vulnerable server does.
For example, consider an application that allows users to import an image by providing a URL:
https://example.com/image.jpgThe server receives that URL, downloads the image, and displays it to the user.
If the application does not properly restrict the destination, an attacker may attempt to make the server request a resource that was never intended to be publicly accessible.
MITRE classifies SSRF as CWE-918: Server-Side Request Forgery. The weakness occurs when a server receives a URL or similar resource reference and does not sufficiently ensure that the request reaches the intended destination.
Why Is SSRF Important?
SSRF is dangerous because servers frequently have more network access than ordinary users.
A production web server might be able to communicate with:
- Internal APIs
- Private databases
- Kubernetes services
- Cloud metadata services
- Monitoring systems
- Internal administration panels
- Redis or other internal services
- Other microservices
- Localhost applications
An attacker who controls the destination of a server-side request may therefore turn a seemingly harmless URL-fetching feature into a bridge toward protected infrastructure.
The impact depends on what the vulnerable server can reach and what the destination does with the request.
SSRF can lead to information disclosure, internal service interaction, credential exposure, network discovery, and in some attack chains further compromise of infrastructure. OWASP specifically highlights cloud metadata, internal REST services, and other internal resources as potential SSRF targets.
How Does an SSRF Attack Work?
A typical SSRF vulnerability follows a relatively simple pattern.
Step 1: The Application Accepts a URL
The application provides functionality that accepts or constructs a destination.
Examples include:
Image URL
Webhook URL
URL preview
Import from URL
PDF generator
Remote document fetcher
API callback
External resource validatorStep 2: The Server Makes the Request
The backend takes the supplied value and makes a network request.
Conceptually:
url = user_input
response = server.fetch(url)The exact implementation differs between languages and frameworks.
The security problem is not that servers make outbound requests. That is often legitimate functionality.
The problem is allowing an untrusted user to determine where those requests go without adequate restrictions.
Step 3: The Attacker Influences the Destination
If destination validation is weak, an attacker can attempt to redirect the server toward an unintended service.
Conceptually:
Public Application
↓
Server-Side HTTP Client
↓
Restricted DestinationThe vulnerable server becomes a proxy-like component.
Step 4: The Response May Be Returned or Used Internally
Depending on the application’s design, the server might return the fetched response to the attacker, process it internally, or use it as input for another operation.
This creates different SSRF impact scenarios.
Common SSRF Attack Surfaces
SSRF does not usually appear randomly. It often appears in features that intentionally communicate with external resources.
Image and File Importers
Applications sometimes allow users to enter a URL to import:
- Images
- Documents
- Videos
- XML files
- JSON data
- Product information
These features deserve careful security review.
Webhooks
Webhook functionality is another common SSRF attack surface.
An application may allow an administrator or customer to specify a callback URL:
Webhook URL → https://customer.example/webhookThe backend then sends an HTTP request to that address.
If destination controls are weak, the same functionality can potentially be abused to reach unintended network locations.
URL Preview Features
Some applications generate previews when users submit a URL.
The backend may:
- Receive the URL.
- Resolve the hostname.
- Connect to the destination.
- Download content.
- Extract metadata.
- Return the preview.
Every step involving attacker-controlled destination data deserves review.
PDF and Screenshot Services
Applications that generate screenshots or PDFs from supplied URLs may also expose SSRF-style risks.
The backend or rendering service must access the requested page. If the destination is not tightly controlled, the rendering service may become an unexpected network client.
API Integrations
Microservices frequently communicate with other services.
An application may receive a URL, hostname, service identifier, or callback location and then use that value to determine where to send a request.
Poor validation can create an SSRF path into internal architecture.
SSRF and Cloud Metadata Services
Cloud environments make SSRF particularly important.
Cloud instances often have access to metadata services that provide information about the running environment. Depending on the cloud platform and configuration, metadata can include credentials, instance information, configuration data, or temporary authorization material.
OWASP specifically warns that SSRF in cloud environments can be used to target metadata services, including AWS, Azure, and Google Cloud metadata infrastructure.
AWS provides Instance Metadata Service version 2 (IMDSv2), which uses session-oriented requests and adds protections against some SSRF scenarios. AWS recommends using IMDSv2 and supported SDKs where appropriate.
This does not mean developers can ignore SSRF.
Cloud metadata protections are an additional security layer. The vulnerable application still needs to restrict where server-side requests can go.
Types of SSRF
SSRF is commonly discussed in several forms depending on how the attacker receives feedback from the server.
Basic SSRF
In a basic SSRF scenario, the application makes a request to an attacker-controlled or unintended destination and the resulting response is visible to the attacker.
For example:
Attacker
↓
Vulnerable Application
↓
Target Service
↓
Response
↓
AttackerThe response makes it easier to determine whether the request reached the target and what the target returned.
Blind SSRF
Blind SSRF occurs when the application makes the server-side request, but the response is not directly returned to the attacker.
The attacker may still be able to determine that a request occurred through indirect evidence.
For authorized testing, security professionals may use controlled infrastructure to observe whether the vulnerable server makes an outbound connection.
Blind SSRF can still be serious because the request itself may interact with sensitive internal services.
Semi-Blind SSRF
Some applications return limited information rather than the complete response.
For example, the application may reveal:
- HTTP status
- Response length
- Timing information
- Error messages
- Redirect behavior
These small differences can still provide useful information during a security assessment.
SSRF vs CSRF
SSRF and CSRF are different vulnerabilities, despite their similar names.
SSRF abuses a server to make an unintended request.
CSRF abuses an authenticated user’s browser to perform an unwanted action.
A simplified comparison:
| Feature | SSRF | CSRF |
|---|---|---|
| Main component abused | Server | Victim’s browser |
| Attacker controls | Server-side destination/request | Forged browser request |
| Common target | Internal/external services | Authenticated web application |
| Main issue | Server trusts an attacker-controlled destination | Server trusts an authenticated browser request |
| Typical defense | Destination validation + network controls | CSRF tokens + origin controls |
Understanding this distinction is important when performing web application assessments.
Real-World SSRF Risks
SSRF has appeared in several serious vulnerability chains over the years.
MITRE’s current CWE-918 references include vulnerabilities involving cloud platforms, mail servers, LLM application frameworks, and URL retrieval functionality. One 2026 example listed by MITRE involves an LLM toolkit that could access arbitrary URLs and was exploited for port scanning.
This is a useful reminder that SSRF is not limited to traditional web applications.
Modern AI and automation systems often retrieve remote content automatically. URL-fetching capabilities in these systems can create SSRF-like attack surfaces when destinations are not sufficiently restricted.
SSRF Prevention Methods
Effective SSRF prevention requires multiple layers.
OWASP recommends a defense-in-depth approach that combines application-layer validation with network-level controls.
Use an Allowlist
The strongest approach, where business requirements permit it, is to define exactly which destinations the application is allowed to contact.
For example:
Allowed:
https://api.example.com
https://images.example.com
Not allowed:
Everything elseThis is significantly stronger than trying to identify every possible malicious destination.
OWASP recommends allowlists when the application’s requirements permit them.
Validate the URL Properly
Do not rely on simple string matching.
A URL contains multiple components:
scheme://hostname:port/pathSecurity validation should consider:
- Scheme
- Hostname
- Port
- IP address
- Redirect behavior
- DNS resolution
- URL parsing differences
Different URL parsers can interpret unusual inputs differently, so applications should use well-tested libraries rather than building URL parsing logic from scratch.
Restrict Protocols
If an application only needs HTTPS, do not allow arbitrary protocols.
For example:
Allowed:
https://
Potentially dangerous when unnecessary:
file://
gopher://
ftp://OWASP notes that SSRF is not limited to HTTP and that applications may potentially interact with other protocols depending on the underlying request mechanism.
Only enable protocols required by the application’s business function.
Restrict Ports
If an application only needs to communicate with an external HTTPS service, there is usually no reason to permit arbitrary ports.
A strict destination policy should define both the permitted host and the permitted port.
Disable Unnecessary Redirects
Redirects can complicate destination validation.
An application may initially validate one destination and then follow a redirect to another destination.
OWASP recommends disabling HTTP redirections where they are not required for the application’s functionality.
If redirects are necessary, validate the final destination as well.
Protect Against DNS Rebinding and TOCTOU Issues
One common mistake is validating a hostname at one point and connecting to it later without ensuring that the destination remains the same.
DNS can change.
This creates a time-of-check/time-of-use problem.
The security control must account for the actual destination used by the network connection rather than assuming that an earlier DNS lookup guarantees safety.
OWASP specifically recommends considering DNS rebinding and TOCTOU behavior when designing SSRF defenses.
Block Private Network Access
Where appropriate, outbound network controls should prevent application servers from reaching unnecessary internal ranges.
Examples include:
- Loopback addresses
- Private IPv4 ranges
- Link-local addresses
- Internal IPv6 ranges
- Cloud metadata endpoints
- Internal management interfaces
However, network blocking should complement application-level allowlisting rather than replace it.
Use Network Segmentation
Network segmentation limits the damage if an SSRF vulnerability exists.
A public-facing web server should not automatically have unrestricted access to every internal service.
Separate sensitive systems into appropriate network zones and permit only required communication paths.
OWASP recommends network segmentation and deny-by-default network controls as part of SSRF defense in depth.
Why Deny Lists Alone Are Weak
A common defensive mistake is creating a list such as:
Block localhost
Block 127.0.0.1
Block 169.254.169.254and assuming the application is now protected.
The problem is that attackers can look for alternative representations, parser inconsistencies, DNS behavior, redirect paths, and other ways to reach an unintended destination.
OWASP explicitly recommends allowlists where possible and describes deny lists as a last resort because they can be bypass-prone.
A better security model is:
What does the application actually need to access?
↓
Define approved destinations
↓
Restrict protocols and ports
↓
Validate the resolved destination
↓
Apply network-level controls
↓
Monitor outbound requestsSSRF Testing Methodology for Penetration Testers
SSRF testing should always be performed against systems you are authorized to assess.
Step 1: Find Server-Side Fetch Functionality
Look for parameters and features such as:
url=
uri=
link=
target=
callback=
webhook=
image=
feed=
redirect=
import=Also inspect JSON requests and API endpoints.
Step 2: Understand the Request Flow
Determine whether the server actually makes an outbound request.
A parameter that looks like a URL does not automatically mean SSRF exists.
The important question is whether server-side code uses the value as a network destination.
Step 3: Use a Controlled Test Destination
During an authorized assessment, use infrastructure controlled by the testing team.
The objective is to verify that the application makes a server-side connection without accessing unauthorized third-party systems.
Step 4: Test Destination Restrictions
After confirming server-side fetching, assess whether the application properly restricts:
- Hostnames
- IP addresses
- Ports
- Protocols
- Redirects
- DNS resolution
- Internal network destinations
Step 5: Determine Impact
Document what the server can reach.
Consider whether the vulnerability can access:
- Internal services
- Administrative interfaces
- Cloud metadata
- Sensitive APIs
- Monitoring systems
- Local services
Do not access sensitive resources simply because a vulnerability makes them technically reachable. Testing should remain within the agreed rules of engagement.
Tools Used for SSRF Testing
Security professionals commonly use:
- Burp Suite
- OWASP ZAP
- Browser Developer Tools
- Controlled HTTP servers
- DNS monitoring infrastructure
- Static analysis tools
- Network monitoring tools
Burp Suite is useful for identifying URL parameters, modifying requests, examining redirects, and understanding how the application processes server-side destinations.
For practical learning, “https://vuln.pentesthint.com/” hands-on labs can help security learners understand SSRF safely through controlled vulnerable environments.
Common SSRF Prevention Mistakes
Trusting User-Supplied URLs
The biggest mistake is assuming that a URL supplied by a user is safe simply because it has a valid format.
A syntactically valid URL can still point somewhere the application should never contact.
Blocking Only Localhost
Blocking one hostname or IP does not solve the underlying problem.
The application needs a broader destination security policy.
Following Redirects Automatically
Automatic redirects can undermine an otherwise reasonable validation system.
If redirects are necessary, each destination should be validated.
Ignoring IPv6
Security controls that only understand IPv4 may overlook IPv6 destinations.
Network validation should account for the address families supported by the application’s network stack.
Returning Raw Responses
If an application retrieves arbitrary content and then returns the entire response to the user, the impact of SSRF can increase significantly.
OWASP’s SSRF guidance recommends avoiding the practice of returning raw responses to clients where possible.
SSRF in Microservices and Cloud-Native Applications
Modern architectures often contain dozens or hundreds of services.
A public API might communicate with:
Internet
↓
API Gateway
↓
Web Application
↓
Internal Services
↓
Databases / Queues / Cloud APIsIf the public-facing application has excessive network access, SSRF can potentially become a bridge into internal infrastructure.
This is why SSRF prevention should not be treated as only an application-code problem.
Architecture matters.
Least-privilege network access, service authentication, segmentation, outbound filtering, and monitoring can significantly reduce the impact of an application-level SSRF flaw.
SSRF and Secure Development
SSRF prevention should begin during application design.
Developers should ask:
- Does this feature really need arbitrary URLs?
- Can destinations be selected from a predefined list?
- Does the application need HTTP and HTTPS, or only HTTPS?
- Are redirects required?
- Which ports are necessary?
- Can the service access private networks?
- Can the service reach cloud metadata?
- What happens if DNS changes?
- Is the response really required by the client?
These questions can eliminate unnecessary attack surface before code reaches production.
For teams building practical application security knowledge, “https://academy.pentesthint.com/” cyber security training can help connect secure development concepts with penetration-testing workflows.
SSRF Security Checklist
A practical SSRF checklist should include:
- Validate all user-controlled URLs.
- Prefer allowlists over deny lists.
- Restrict schemes to those actually required.
- Restrict destination ports.
- Validate hostnames and resolved addresses.
- Prevent access to unnecessary private networks.
- Consider IPv4 and IPv6.
- Disable redirects when possible.
- Validate redirect destinations when redirects are required.
- Protect cloud metadata services.
- Use network segmentation.
- Apply least-privilege outbound network access.
- Avoid returning raw remote responses.
- Log unusual outbound requests.
- Monitor unexpected DNS and network activity.
- Test URL-fetching functionality during security assessments.
Frequently Asked Questions
What is Server-Side Request Forgery (SSRF)?
Server-Side Request Forgery is a vulnerability where an attacker influences a server into making a network request to an unintended destination. The destination may be an external service, internal application, localhost service, or cloud metadata endpoint.
How does an SSRF attack work?
An SSRF attack typically starts with a feature that allows the application to fetch or connect to a URL. If the application does not adequately validate the destination, an attacker may influence the server into communicating with a resource that should not be accessible.
What is the difference between SSRF and CSRF?
SSRF abuses the server’s ability to make outbound requests. CSRF abuses a victim’s authenticated browser to make an unwanted request to a web application.
Why is SSRF dangerous in cloud environments?
Cloud environments can expose metadata services containing sensitive configuration or temporary credentials. If a vulnerable server can access those services, SSRF can potentially become a path to sensitive cloud information. OWASP specifically identifies cloud metadata services as an important SSRF risk.
How can developers prevent SSRF?
The strongest approach is usually to restrict server-side requests to approved destinations. Developers should also validate URLs, restrict schemes and ports, control redirects, prevent unnecessary private-network access, and use network segmentation and outbound filtering as defense in depth.
Is a deny list enough to prevent SSRF?
No. Deny lists can be bypass-prone because there may be multiple ways to represent or resolve a destination. OWASP recommends allowlists whenever the application’s requirements make them practical.
What is CWE-918?
CWE-918 is the MITRE Common Weakness Enumeration entry for Server-Side Request Forgery. It describes cases where a server receives a URL or similar resource reference and fails to sufficiently ensure that the request reaches the intended destination.
Can SSRF be blind?
Yes. In blind SSRF, the server makes the request but does not return the response directly to the attacker. Controlled external infrastructure can sometimes be used during authorized testing to verify that the server made the outbound connection.
External Resources
For deeper technical guidance, the OWASP SSRF Prevention Cheat Sheet provides detailed application- and network-level defenses.
The MITRE CWE-918 reference is useful when documenting SSRF findings and understanding the underlying weakness classification.
For AWS environments, the AWS EC2 Instance Metadata Service documentation explains IMDSv2 and its session-oriented request model.
Conclusion
Server-Side Request Forgery is fundamentally a trust problem.
The application trusts a destination supplied or influenced by an untrusted party, and the server then uses its own network privileges to access that destination.
The risk becomes much greater when the vulnerable application can communicate with internal services, cloud metadata systems, management interfaces, or other sensitive infrastructure.
The most effective SSRF defense is not a single blacklist or regular expression. A stronger approach combines strict destination allowlisting, protocol and port restrictions, safe URL handling, redirect controls, DNS-aware validation, network segmentation, outbound filtering, and cloud-specific protections.
For penetration testers, the key is to understand the complete request flow: where the destination enters the application, how the server resolves it, where the connection goes, and what the application does with the response.
If you’re building practical web application security skills, explore “https://pentesthint.com/” PentestHint for security resources and “https://vuln.pentesthint.com/” vulnerability labs for controlled hands-on practice.
