Server-side request forgery, commonly shortened to SSRF, is a web security vulnerability that allows an attacker to manipulate a server into making an unintended network request.
The attacker is not necessarily accessing the target resource directly. Instead, they abuse a vulnerable website, API, or application as an intermediary. Because the request comes from a trusted server, it may reach systems that are not accessible from the public internet.
A successful SSRF attack may expose internal services, cloud credentials, administrative interfaces, sensitive files, or protected application data. In severe cases, it can help an attacker move deeper into an organization’s network or compromise cloud infrastructure.
How Does an SSRF Attack Work?
Modern applications frequently retrieve information from other locations. A website might:
- Import an image from a URL
- Generate a preview for a shared link
- Download a document
- Check whether a webhook is working
- Connect to an external API
- Convert an online file
- Fetch a profile picture
- Scan a remote website
- Validate a feed
- Send data to a callback address
These features are not inherently unsafe. The vulnerability appears when an application allows a user to control all or part of the destination without applying strong restrictions.
A typical SSRF attack follows this pattern:
- The application accepts a URL, hostname, IP address, or destination from a user.
- The server uses that information to make a request.
- The application does not properly validate or restrict the destination.
- The attacker changes the destination to an unintended resource.
- The server sends the request using its own network position and permissions.
- The attacker observes the response or another effect of the request.
The vulnerable server may be able to access internal resources that the attacker cannot reach directly because of a firewall, VPN, network boundary, or authentication rule.
OWASP explains that SSRF can abuse URL-fetching functionality to read or update internal resources. OWASP’s SSRF overview describes how features that import or publish data through URLs can become vulnerable.
Why Is SSRF Dangerous?
Servers often have more network access and trust than ordinary internet users.
A public-facing application may be allowed to communicate with:
- Internal APIs
- Databases
- Administrative services
- Monitoring platforms
- Cloud metadata services
- Container-management systems
- Private storage
- Development tools
- Message queues
- Authentication services
- Other application servers
An attacker who controls where the server sends requests may bypass the security boundary protecting these services.
Possible consequences include:
- Internal network scanning
- Sensitive-data exposure
- Cloud credential theft
- Access to private APIs
- Administrative action
- Reading local or remote files
- Service disruption
- Firewall bypass
- Authentication bypass
- Internal service exploitation
- Movement into other systems
- Remote code execution when combined with another weakness
The precise impact depends on the server’s network access, identity, supported protocols, response handling, and privileges.
Common Features That May Create SSRF Risk
SSRF vulnerabilities frequently appear in features that accept remote locations.
Examples include:
- Image importers
- PDF generators
- Link preview services
- Webhook testing tools
- URL validators
- Document converters
- Website screenshot tools
- Social media previews
- File-upload-by-URL functions
- Calendar integrations
- RSS and XML feed readers
- Proxy services
- Video thumbnail generators
- SSO integrations
- Cloud automation tools
- Server-side analytics
- API gateways
Developers should also examine less obvious inputs, including HTTP headers, XML files, redirects, embedded metadata, and stored values later used by a background service.
Common Types of SSRF
Basic or Non-Blind SSRF
In a basic SSRF attack, the application returns information from the server’s unintended request to the attacker.
For example, a vulnerable URL-preview feature may display the content retrieved from an internal service.
Because the attacker receives a direct response, the vulnerability may allow easier discovery of accessible resources.
Blind SSRF
Blind SSRF occurs when the application makes the server-side request but does not return the response to the attacker.
The attacker may still detect the request through:
- A callback to an external system they control
- Changes in response time
- Application errors
- Different HTTP status codes
- Side effects on an internal service
- Security monitoring alerts
Blind SSRF can still be highly dangerous, particularly when the server can send state-changing requests or reach other vulnerable services.
Semi-Blind SSRF
In a semi-blind attack, the application reveals limited information rather than the complete response.
It may expose:
- Whether the request succeeded
- The response size
- A status code
- A page title
- Processing time
- A generic error category
These small differences can help an attacker map internal systems.
Internal Network SSRF
An attacker may use a vulnerable server to request private network addresses or internal hostnames.
This can expose services that assume they are safe because they are inaccessible from the public internet. Internal services may have weak authentication, outdated software, or powerful administrative functions.
Network location should never be treated as the only form of authentication.
Cloud Metadata SSRF
Cloud environments may provide metadata services to workloads. These services can supply configuration information and, depending on the platform and setup, temporary identity credentials.
An SSRF vulnerability may allow the application server to request information from its cloud metadata service. Stolen credentials could give the attacker access to storage, secrets, databases, or other cloud resources.
Cloud providers offer stronger metadata protections, but organizations must enable and correctly configure them.
Local Resource SSRF
Some URL-processing libraries support more than HTTP and HTTPS. If dangerous protocols are allowed, an attacker may attempt to make the application access local files or other resources.
Applications should explicitly permit only the protocols required for the business function.
Second-Order SSRF
Second-order SSRF occurs when an unsafe destination is stored first and requested later.
For example, an application may save a webhook address during account setup. A background service may later connect to that address without validating it again.
The delayed request can make the vulnerability more difficult to identify because submission and execution happen at different times.
Redirect-Based SSRF
An application may initially approve a permitted URL, but that destination responds with a redirect to a prohibited location.
If the server follows redirects without validating every new destination, an attacker may bypass the original check.
The application should either disable redirects or revalidate the destination after every redirect.
What Is the Difference Between SSRF and CSRF?
The abbreviations sound similar, but the attacks involve different victims and trust relationships.
CSRF tricks a user’s authenticated browser into sending an unwanted request to a website.
SSRF tricks an application server into sending an unintended request to another resource.
In CSRF, the browser is the intermediary. In SSRF, the server is the intermediary.
CSRF usually abuses the user’s session. SSRF usually abuses the server’s network access, application identity, or trusted position.
What Is the Difference Between SSRF and Open Redirect?
An open redirect sends the user’s browser to an attacker-selected destination. An SSRF vulnerability makes the server itself contact an attacker-selected destination.
An open redirect can support phishing. SSRF can expose internal systems that the browser or attacker cannot access directly.
The two vulnerabilities may be combined if the server follows a redirect without revalidating its destination.
What Is the Difference Between SSRF and SQL Injection?
SQL injection manipulates database queries. SSRF manipulates outbound requests made by a server.
Both vulnerabilities result from allowing untrusted input to influence a sensitive operation. However, their targets and primary defenses are different.
SQL injection is primarily prevented through parameterized database queries. SSRF requires strict destination validation, network restrictions, safe URL parsing, and controlled outbound access.
Warning Signs of an SSRF Attack
Users will rarely notice SSRF directly because the activity occurs on the server.
Developers and security teams may observe:
- Requests to private or loopback addresses
- Unexpected DNS lookups
- Outbound traffic to unfamiliar hosts
- Requests to cloud metadata services
- Connections to unusual ports
- A URL-fetching feature scanning many addresses
- Repeated malformed URL submissions
- Requests using unsupported protocols
- Sudden traffic between application and internal services
- Unexpected authentication failures inside the network
- Internal service errors following public API requests
- Unusual response-time patterns
- Outbound requests containing sensitive information
- Attempts to use redirects to reach blocked destinations
- Application servers accessing systems outside their normal role
A single unusual request may have a legitimate explanation. Detection should consider the application’s expected behavior, user identity, destination, timing, and request pattern.
How Can Developers Prevent SSRF?
Avoid User-Controlled Destinations Where Possible
The strongest defense is to avoid giving users direct control over server-side request destinations.
Instead of accepting an arbitrary URL, the application can:
- Offer a list of approved services
- Accept a record identifier
- Map a user selection to a server-controlled destination
- Use a dedicated integration configuration
- Retrieve content through a restricted internal service
Reducing flexibility can substantially reduce the attack surface.
Use a Strict Allowlist
When the application needs to contact a limited set of known services, maintain an allowlist of approved:
- Domains
- IP addresses
- Ports
- Protocols
- Paths
- Service identifiers
The application should reject everything that is not explicitly allowed.
Comparisons must be exact and based on a safely parsed value. Loose substring checks are dangerous because an attacker may construct a hostname that merely contains an approved name.
OWASP notes that destination allowlisting provides the strongest protection when an application communicates only with identified trusted services. Its SSRF Prevention Cheat Sheet outlines validation for different application scenarios.
Parse URLs With a Trusted Library
URLs are complex. They can contain:
- User information
- Encoded characters
- Alternative address formats
- Internationalized domain names
- Ports
- Fragments
- Redirects
- Multiple separators
- Unusual schemes
Developers should use a maintained URL parser rather than attempting to interpret URLs with regular expressions or string splitting.
Validation should occur on the parser’s normalized output.
Restrict Permitted Protocols
If the feature needs only HTTPS, allow only HTTPS.
Do not permit unnecessary schemes or protocols. The application should reject any destination type not explicitly required for its function.
Protocol restrictions must be enforced after parsing and normalization.
Block Private and Special-Use Addresses
Applications that retrieve public internet resources should block destinations resolving to:
- Loopback addresses
- Private network ranges
- Link-local addresses
- Cloud metadata services
- Multicast addresses
- Unspecified addresses
- Reserved address ranges
- Internal IPv6 ranges
The checks must support both IPv4 and IPv6. Developers should use reliable IP-address libraries rather than custom string comparisons.
Validate DNS Resolution Carefully
Hostname validation must account for the possibility that a domain resolves differently over time or returns multiple addresses.
The application should:
- Resolve the hostname using a trusted resolver
- Check every returned IP address
- Reject private and prohibited destinations
- Connect to the validated address
- Protect against DNS rebinding
- Revalidate when appropriate
- Avoid unnecessary reliance on external DNS
Validating a hostname once and connecting to a different address later can create a gap between checking and use.
Revalidate Every Redirect
If redirects are permitted, validate each new destination before following it.
A request that begins at an approved public URL may redirect to an internal service. The application should enforce the same protocol, hostname, address, and port policies at every step.
Disabling automatic redirects is safer when the business feature does not require them.
Restrict Outbound Network Access
Application servers should not be able to connect to every system and port.
Network controls can limit outbound traffic through:
- Egress firewalls
- Network security groups
- Service meshes
- Proxy gateways
- Container network policies
- Cloud firewall rules
- Segmentation
- Dedicated fetching services
Allow only the destinations and ports required by the application.
This is crucial because input validation can fail or be bypassed. Network controls provide a separate security layer.
Separate the Fetching Service
Applications with URL-preview or remote-content features can route requests through a dedicated service with:
- No access to internal networks
- Minimal credentials
- Restricted outbound destinations
- Limited protocols
- Strict timeouts
- Response-size limits
- Isolated storage
- Detailed monitoring
If the service is compromised, the isolation reduces its ability to reach sensitive infrastructure.
Protect Cloud Metadata Services
Organizations should use the cloud provider’s recommended metadata protections.
Depending on the platform, this may include:
- Requiring session-oriented metadata access
- Blocking metadata addresses at the application layer
- Restricting workload identity permissions
- Using network controls
- Disabling metadata access where unnecessary
- Monitoring metadata requests
- Applying least privilege to temporary credentials
A strong metadata configuration reduces the impact if SSRF occurs.
Apply Least Privilege
The server’s identity should have only the permissions needed for its role.
Limit access to:
- Cloud storage
- Secrets
- Databases
- Administrative APIs
- Message queues
- Deployment systems
- Other workloads
An SSRF vulnerability becomes far more damaging when the application server has broad permissions.
Limit Request Capabilities
A remote-fetching feature should apply:
- Connection timeouts
- Read timeouts
- Response-size limits
- Content-type restrictions
- Port restrictions
- Redirect limits
- Download limits
- Rate limits
- Method restrictions
- Header restrictions
These controls reduce the opportunity for network scanning, large downloads, and service disruption.
Do Not Forward Sensitive Headers
The application should not automatically forward:
- Session cookies
- Authorization headers
- Internal API keys
- Client certificates
- Proxy credentials
- Tracing headers containing sensitive data
Credentials intended for one service must not be sent to an attacker-controlled or unintended destination.
Why Input Validation Alone Is Not Enough
SSRF defenses are difficult because URLs and network destinations can be represented in many ways.
An attacker may attempt to use:
- Alternative IP representations
- IPv6
- DNS changes
- Redirects
- Encoded characters
- Confusing hostname structures
- Parser inconsistencies
- User-information sections in URLs
- Unusual ports
- Unsupported protocols
Applications need layered protection: safe parsing, allowlisting, IP validation, redirect checks, outbound network restrictions, and least privilege.
MITRE classifies SSRF as CWE-918 and notes that it may expose internal or restricted resources such as administrative panels and cloud metadata endpoints. MITRE’s CWE-918 entry documents the weakness.
How Should Organizations Monitor for SSRF?
Security teams should establish a baseline of normal outbound traffic for each application.
Useful monitoring includes:
- DNS query logs
- Proxy logs
- Firewall events
- Cloud network-flow logs
- Application URL-fetch logs
- Metadata service access
- Internal API activity
- Container network events
- Unusual destination ports
- Redirect behavior
- Outbound request volume
Alerts should focus on application servers contacting destinations unrelated to their normal function.
Logs should capture enough detail for investigation without recording secrets or sensitive response content unnecessarily.
How Should SSRF Be Tested?
SSRF testing should occur only with explicit authorization and in a controlled environment.
A security assessment may review:
- Every feature that accepts a URL or hostname
- Background jobs that retrieve external content
- Webhook configuration
- Redirect handling
- Protocol restrictions
- IPv4 and IPv6 validation
- DNS resolution behavior
- Cloud metadata protections
- Outbound firewall rules
- Forwarded authentication headers
- API and mobile endpoints
- File conversion and preview services
Source-code review is important because some server-side requests may not be obvious through the user interface.
Automated tools can assist with testing, but manual review is often needed to understand redirects, asynchronous requests, network controls, and business logic.
What Should an Organization Do After Detecting SSRF?
Contain the Vulnerable Feature
Possible containment steps include:
- Disabling the affected function
- Restricting it to trusted users
- Blocking outbound access
- Applying emergency destination rules
- Isolating the server
- Disabling redirect following
- Blocking metadata endpoints
- Revoking unnecessary network permissions
Containment should reduce risk without destroying evidence.
Preserve Evidence
Collect relevant information, including:
- Application logs
- URL submissions
- Authentication records
- DNS queries
- Outbound firewall logs
- Proxy activity
- Cloud audit events
- Internal service logs
- Metadata access records
- Temporary credentials used by the workload
Follow established incident-response and evidence-handling procedures.
Determine What the Server Accessed
Investigators should identify:
- Requested destinations
- Ports and protocols
- Internal services reached
- Information returned to the attacker
- Requests that caused state changes
- Credentials exposed
- Files accessed
- Cloud APIs called
- Additional vulnerabilities targeted
An SSRF vulnerability may be only the initial access path. Related systems must also be investigated.
Rotate Exposed Credentials
If the server may have accessed metadata services, secrets, configuration files, or authenticated internal APIs, rotate potentially exposed:
- Cloud credentials
- API tokens
- Database passwords
- Service-account keys
- Application secrets
- Signing keys
- Administrative credentials
Temporary credentials may expire automatically, but organizations should still review how they were used.
Fix the Root Cause
Replace unrestricted URL fetching with:
- Server-controlled destination mapping
- Strict allowlists
- Safe parsing
- IP-range blocking
- Redirect validation
- Protocol restrictions
- Egress controls
- Least-privilege identities
Review similar functions across the entire product.
Patch Related Systems
If the SSRF request reached an internal service, update and secure that service. Internal applications should require authentication and should not depend solely on network location for protection.
Monitor After Recovery
Continue monitoring for:
- Repeated requests to the vulnerable endpoint
- Attempts to reach internal addresses
- Metadata service access
- Use of exposed credentials
- New cloud resources
- Unusual outbound connections
- Changes to internal accounts
- Signs of lateral movement
What Should a Customer Do If a Service Reports an SSRF Incident?
Most users cannot directly fix an SSRF vulnerability because it exists in the service provider’s server-side code.
If a provider reports that your information may have been affected:
- Read the official incident notice
- Change credentials the provider identifies as exposed
- Rotate API tokens
- Review connected applications
- Check account activity
- Remove unfamiliar integrations
- Enable multi-factor authentication
- Follow any service-specific recovery steps
- Watch for phishing related to the incident
Use the provider’s official website rather than links in unexpected emails.
Can a Web Application Firewall Stop SSRF?
A WAF may block known malicious inputs or obvious requests to prohibited addresses, but it cannot reliably prevent every SSRF attack.
Attackers may use redirects, encoding, DNS behavior, alternative address formats, or application-specific URL structures.
The application must validate destinations correctly, and the network should independently restrict outbound access.
Does HTTPS Prevent SSRF?
No. HTTPS protects traffic between systems, but it does not determine whether the destination is authorized.
A vulnerable server can make an unintended request over a perfectly encrypted HTTPS connection.
Can SSRF Lead to Remote Code Execution?
Sometimes. SSRF alone primarily allows unintended server-side requests. It may lead to remote code execution when the accessible internal service has a dangerous administrative function, weak authentication, or another exploitable vulnerability.
This is why internal services should require authentication, use least privilege, and remain patched even when they are not exposed publicly.
Is SSRF Only a Cloud Security Problem?
No. SSRF can affect traditional data centers, internal corporate networks, container platforms, and cloud environments.
Cloud services receive particular attention because metadata endpoints and workload identities can provide access to powerful temporary credentials. The underlying vulnerability, however, can exist anywhere a server retrieves a user-controlled destination.
Why Is SSRF Included in the OWASP Top 10?
SSRF appears in the OWASP Top 10 because modern applications frequently connect to remote services, APIs, and cloud resources. Unsafe server-side fetching can cross important trust boundaries and expose resources protected from direct internet access.
OWASP also includes SSRF in its API Security risks because APIs frequently accept URLs for webhooks, imports, integrations, and remote file processing. OWASP’s API Security guidance explains that an API becomes vulnerable when it fetches a user-supplied URL without validating the destination.
