SSRF Vulnerability: What It Is, How It Works, and How to Prevent Server-Side Request Forgery

In 2019, a researcher discovered that Capital One's web application firewall could be tricked into making requests to the AWS metadata service. That single SSRF vulnerability exposed 106 million customer records, resulting in an $80 million fine and one of the largest data breaches in financial services history.

The server didn't have a SQL injection. It didn't have an authentication bypass. It had a feature that made HTTP requests on behalf of users, and that feature could be pointed at internal resources the server had access to but users never should.

That's what Server-Side Request Forgery is. Your server makes HTTP requests as part of normal functionality: fetching URLs for link previews, importing data from external sources, processing webhooks, generating PDF thumbnails, validating URLs. SSRF happens when an attacker manipulates those requests to target internal systems, cloud metadata services, or other resources the server can reach but the attacker cannot access directly.

SSRF earned its place in the OWASP Top 10 (2021) as A10 because the vulnerability class has become dramatically more dangerous in cloud environments. When your server runs on AWS, Azure, or GCP, the metadata service at 169.254.169.254 is accessible from the server but not from the internet. SSRF bridges that gap, letting an attacker use your server as a proxy to access internal infrastructure, cloud credentials, and services that network architecture was supposed to protect.

This guide covers how SSRF vulnerabilities work, the types of SSRF attacks, real-world exploitation techniques including cloud metadata attacks, common bypass methods used when basic protections exist, how to detect SSRF in your applications, prevention strategies that actually work, and how professional penetration testing identifies SSRF before attackers do.

What Is SSRF (Server-Side Request Forgery)?

Server-Side Request Forgery is a vulnerability where an attacker can make the server-side application send HTTP requests to an unintended destination. The attacker doesn't make the request directly. They manipulate the application into making the request on their behalf, using the server's network position, credentials, and access to reach resources the attacker cannot access from outside.

Why SSRF Is Dangerous

The danger of SSRF lies in network position. Your server sits inside your network infrastructure. It can reach internal services (databases, admin panels, monitoring systems), cloud metadata endpoints (containing temporary credentials, configuration data), other applications in the private network, and backend services not exposed to the internet.

When an attacker controls which URLs your server requests, they inherit the server's network access. Every internal service, metadata endpoint, and private resource reachable by the server becomes reachable by the attacker through the SSRF vulnerability.

How SSRF Differs from Other Request-Based Attacks

SSRF vs CSRF (Cross-Site Request Forgery): CSRF tricks the user's browser into making requests. SSRF tricks the server into making requests. CSRF uses the user's session and browser context. SSRF uses the server's network position and service identity.

SSRF vs Open Redirect: Open redirects send the user's browser to an unintended URL. SSRF sends the server to an unintended URL. Open redirects affect the client side. SSRF affects the server side with access to internal infrastructure.

How SSRF Attacks Work

The Basic SSRF Pattern

1. The application accepts a URL as user input (or in a parameter the user can control)
2. The server-side code fetches the content at that URL
3. The attacker provides a URL pointing to an internal resource instead of an external one
4. The server fetches the internal resource and returns the content (or processes it)
5. The attacker receives data from a resource they couldn't reach directly

Common Vulnerable Functionality

SSRF vulnerabilities appear wherever applications make server-side HTTP requests based on user-controllable input.

URL preview and link expansion. Social platforms, messaging apps, and CMS systems that fetch URLs to generate link previews. The user provides a URL, the server fetches it to extract title, description, and thumbnail.

Vulnerable pattern: User submits url=https://internal-admin.company.local/ and the server fetches internal admin panel content.

File import from URL. Applications allowing users to import files, images, or data from external URLs. Document processing, image manipulation, and data import features.

Vulnerable pattern: User submits importUrl=http://169.254.169.254/latest/meta-data/iam/security-credentials/ and the server fetches AWS credentials.

Webhook delivery. Applications sending webhook notifications to user-configured URLs. The server makes POST requests to URLs the user specifies.

Vulnerable pattern: User configures webhook URL as http://internal-database:5432/ and the server sends requests to the internal database.

PDF and document generation. Server-side rendering that converts URLs or HTML to PDF documents. HTML-to-PDF converters that resolve URLs, images, and stylesheets.

Vulnerable pattern: User provides HTML containing <img src="http://169.254.169.254/latest/meta-data/"> and the PDF renderer fetches cloud metadata.

URL validation and checking. Features that validate whether a provided URL is accessible, check if a website is online, or verify URL ownership.

Vulnerable pattern: User submits checkUrl=http://10.0.0.1:8080/admin and the server verifies (and returns information about) an internal admin interface.

Image processing. Applications that resize, crop, or transform images from user-provided URLs.

Vulnerable pattern: User submits imageUrl=http://internal-service/sensitive-data and the image processor fetches internal content.

Types of SSRF

Basic (In-Band) SSRF

The server fetches the attacker-specified URL and returns the response content directly to the attacker. This is the most straightforward SSRF type because the attacker sees the response immediately.

Impact: Direct access to internal resource content. The attacker can read internal web pages, API responses, configuration files, and service outputs.

Blind SSRF

The server fetches the attacker-specified URL but doesn't return the response content to the attacker. The attacker knows the request was made but cannot directly see the response.

Detection techniques: Testers use out-of-band interaction detection (monitoring DNS lookups or HTTP requests to attacker-controlled servers). If the target server makes a request to the attacker's server, SSRF is confirmed even without seeing the response.

Impact: Blind SSRF is still dangerous. Attackers can port-scan internal networks (different response times or error messages reveal open/closed ports), trigger actions on internal services (HTTP requests that modify state), and access cloud metadata services where the response content is processed internally by the application.

Semi-Blind SSRF

The server doesn't return the full response but reveals partial information through error messages, response timing, or HTTP status codes. The attacker infers internal information from these side channels.

SSRF Exploitation Techniques

Cloud Metadata Attacks

The highest-impact SSRF exploitation in modern environments. Cloud providers expose instance metadata through HTTP endpoints accessible only from within the instance.

AWS metadata (IMDSv1):http://169.254.169.254/latest/meta-data/ exposes instance identity, network configuration, and IAM role credentials. IAM credentials obtained through SSRF provide authenticated access to AWS services (S3, DynamoDB, Lambda) with whatever permissions the instance role grants.

AWS IMDSv2 mitigates this by requiring a token obtained through a PUT request, which many SSRF vectors cannot make. However, applications using older SDK versions or custom metadata fetching may still use IMDSv1.

Azure metadata:http://169.254.169.254/metadata/instance?api-version=2021-02-01 with Metadata: true header exposes instance details and managed identity tokens.

GCP metadata:http://metadata.google.internal/computeMetadata/v1/ with Metadata-Flavor: Google header exposes project information, service account tokens, and instance attributes.

Cloud metadata SSRF was the attack vector in the Capital One breach. The attacker used SSRF to retrieve temporary AWS credentials from the metadata service, then used those credentials to access S3 buckets containing 106 million customer records.

For cloud security testing methodology, see our cloud penetration testing guide and platform-specific guides for AWS, Azure, and GCP.

Internal Network Scanning

SSRF enables port scanning and service discovery across the internal network. By submitting requests to internal IP addresses with different ports, the attacker maps internal services based on response behaviour: response time (open ports respond faster), error messages (different errors for open vs closed ports), and response size (varies by service).

Internal scanning through SSRF reveals what services run on internal networks, which ports are open on internal hosts, and which internal IP addresses are active.

Internal Service Access

Once internal services are discovered, SSRF enables direct interaction. Internal admin panels often lack authentication because they're "only accessible internally." Internal APIs may accept requests without credentials because they trust the source network. Internal databases, caches (Redis, Memcached), and message queues may accept commands from any internal host.

Protocol Smuggling

Some SSRF vulnerabilities allow non-HTTP protocols. Using gopher://, dict://, file://, or other protocol handlers, attackers interact with internal services that don't speak HTTP. The gopher:// protocol is particularly dangerous because it allows constructing arbitrary TCP packets, enabling interaction with Redis, SMTP, and other non-HTTP services through an HTTP-based SSRF.

DNS Rebinding

An advanced SSRF bypass technique. The attacker controls a domain that initially resolves to a safe external IP (passing validation), then quickly re-resolves to an internal IP (169.254.169.254 or 10.0.0.x). The time-of-check to time-of-use gap means the application validates the domain against a safe IP but fetches content from an internal IP.

Common SSRF Bypass Techniques

When applications implement basic SSRF protections, attackers use bypass techniques to circumvent them.

IP Address Obfuscation

Basic blocklists blocking 127.0.0.1 and 169.254.169.254 can be bypassed through alternative representations.

Decimal encoding: http://2130706433 (decimal representation of 127.0.0.1)Hex encoding: http://0x7f000001Octal encoding: http://0177.0.0.1IPv6 equivalents: http://[::1] (localhost), http://[::ffff:127.0.0.1]Zero-expanded: http://127.0.0.000000001Shortened: http://127.1 (resolves to 127.0.0.1 on most systems)

Redirect Bypass

If the application follows redirects, the attacker provides an external URL that passes validation, which then redirects to an internal target. The application validates the initial URL but follows the redirect to the internal resource.

DNS Rebinding

As described above, the domain resolves to a safe IP during validation but re-resolves to an internal IP during the actual request.

URL Parser Inconsistencies

Different URL parsing libraries interpret ambiguous URLs differently. An attacker crafts URLs that one parser (the validator) interprets as safe but another parser (the HTTP client) interprets as internal. For example, URLs with embedded credentials (http://attacker.com@internal-server/), URL fragment confusion, or backslash/forward-slash handling differences.

Protocol Handler Abuse

Switching from http:// to file://, gopher://, dict://, or other protocol handlers to bypass HTTP-specific protections and interact with internal resources through different protocols.

How to Detect SSRF in Your Applications

Code Review Indicators

Review application code for SSRF vulnerability patterns.

High-risk functions (by language):

Python: requests.get(), urllib.request.urlopen(), httpx.get() where the URL parameter is user-controllable.

Java: HttpURLConnection, HttpClient, RestTemplate, WebClient with user-controllable URLs.

Node.js: fetch(), axios.get(), http.get(), node-fetch with user-controllable URLs.

PHP: file_get_contents(), curl_exec(), fopen() with user-controllable URLs.

Ruby: Net::HTTP, open-uri, HTTParty with user-controllable URLs.

Any function that makes an HTTP request where the URL (or any part of it: scheme, host, port, path) comes from user input is a potential SSRF vector.

Dynamic Testing Indicators

During web application penetration testing, testers identify SSRF through out-of-band interaction testing (does the server make requests to attacker-controlled domains?), internal IP response differences (does http://127.0.0.1 produce different behaviour than http://google.com?), timing analysis (do internal IPs respond faster than external URLs?), and error message analysis (do different targets produce different error messages?).

Automated Scanning Limitations

Automated scanners detect basic SSRF patterns but consistently miss SSRF in complex application logic, webhook configurations, file processing pipelines, and multi-step workflows. Manual penetration testing is essential for thorough SSRF detection because the vulnerability often exists in application-specific functionality that scanners don't understand.

How to Prevent SSRF

Defence in Depth: Multiple Layers Required

No single control prevents all SSRF. Effective SSRF prevention requires layered defences.

Layer 1: Input Validation

Allowlist approach (strongest). Maintain an explicit allowlist of permitted domains and IPs the application is allowed to request. Reject any URL not matching the allowlist. This is the strongest control when the set of legitimate destinations is known and finite.

Blocklist approach (weaker, necessary as supplement). Block requests to internal IP ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 127.0.0.0/8), cloud metadata addresses (169.254.169.254), and link-local addresses (169.254.0.0/16). Blocklists are necessary but insufficient alone because bypass techniques circumvent string-based blocking.

URL parsing validation. Parse the URL using your language's standard URL parser and validate the resolved hostname/IP after parsing rather than matching against the raw URL string. This prevents many encoding-based bypasses.

DNS resolution validation. Resolve the hostname to an IP address and validate the resolved IP against your blocklist before making the request. This prevents some DNS rebinding attacks (validate after resolution, not before).

Layer 2: Network Controls

Egress filtering. Configure network-level controls (security groups, firewall rules, network policies) restricting which destinations the application server can reach. Deny access to metadata services, internal management networks, and sensitive services from application servers that don't need them.

Instance metadata protection. On AWS, enforce IMDSv2 (requiring token-based metadata access). IMDSv2 requires a PUT request to obtain a session token before accessing metadata, which most SSRF vectors cannot perform because they're limited to GET requests.

On Azure, use managed identity with restrictive permissions. On GCP, restrict service account permissions and metadata API access.

Network segmentation. Isolate application servers from sensitive internal services through network segmentation. Even if SSRF occurs, segmentation limits what the server can reach. Application servers don't need direct access to database management interfaces, infrastructure monitoring, or other internal services.

Layer 3: Application Architecture

Dedicated request service. Route all user-triggered HTTP requests through a dedicated service with its own restricted network access. This service has no access to internal infrastructure, cloud metadata, or sensitive services. The application delegates URL fetching to this restricted service rather than making requests from the main application server.

Response validation. After fetching a URL, validate that the response content matches expected format before processing. If you're fetching images, validate the response is actually an image. If you're fetching JSON, validate the response is valid JSON matching expected schema. Don't blindly process or return arbitrary response content.

Disable unnecessary protocols. Restrict URL schemes to http and https only. Block file://, gopher://, dict://, ftp://, and other protocol handlers that enable protocol smuggling.

Disable or restrict redirects. If the application follows HTTP redirects, validate the redirect destination against the same blocklist/allowlist applied to the original URL. Better yet, don't follow redirects automatically for user-provided URLs.

SSRF Prevention Checklist

• Allowlist implemented for permitted request destinations (where possible)
• Blocklist covering all internal IP ranges, metadata addresses, and link-local addresses
• URL parsed and hostname resolved before validation (not string matching)
• DNS resolution validated against blocklist (resolved IP, not hostname)
• URL schemes restricted to http/https only
• HTTP redirect following disabled or redirect destinations validated
• AWS IMDSv2 enforced (if running on AWS)
• Network-level egress filtering restricting server outbound connections
• Application servers segmented from sensitive internal services
• Response content validated before processing
• SSRF testing included in regular web application security testing

SSRF in the OWASP Top 10

SSRF was added to the OWASP Top 10 in the 2021 edition as A10: Server-Side Request Forgery. Its inclusion reflects the increasing prevalence and impact of SSRF in cloud-native applications where internal metadata services create high-value SSRF targets.

OWASP's SSRF guidance aligns with the prevention strategies above: input validation (allowlists over blocklists), network-level controls (egress filtering, metadata protection), and application architecture (dedicated request services, protocol restriction).

Understanding SSRF within the broader OWASP Top 10 context is essential for comprehensive web application penetration testing. For complete OWASP Top 10 testing coverage, see our web application security testing checklist.

How Professional Penetration Testing Finds SSRF

Why Automated Scanners Miss SSRF

Automated web application scanners test for basic SSRF by injecting internal IP addresses into URL parameters. This catches the simplest SSRF patterns. Scanners consistently miss SSRF in webhook configuration (requires understanding application workflow), file import functionality (requires specific input formats), multi-step processes where the URL is submitted in one step and fetched in another, PDF generation and document processing (requires understanding rendering pipeline), and complex API interactions where URLs are embedded in JSON/XML payloads.

How Manual Testers Find SSRF

Professional penetration testers approach SSRF discovery differently.

Functionality mapping. Testers map every application feature that makes server-side HTTP requests: URL previews, webhooks, file imports, integrations, and any feature accepting URLs or fetching external content.

Out-of-band testing. Testers use attacker-controlled servers (Burp Collaborator, interactsh) to detect blind SSRF where the application makes requests but doesn't return responses. DNS and HTTP callbacks confirm the server is making requests to attacker-specified destinations.

Bypass testing. After identifying potential SSRF, testers systematically attempt bypass techniques: IP encoding, redirect chains, DNS rebinding, protocol handlers, and URL parser inconsistencies. Basic protections are tested for circumvention before concluding the application is secure.

Impact assessment. Confirmed SSRF is assessed for maximum impact: metadata access, internal service interaction, credential retrieval, and data exfiltration. Testers demonstrate business impact through controlled exploitation.

SSRF testing is a standard component of professional VAPT engagements.

How AppSecure Tests for SSRF

AppSecure's web application penetration testing includes comprehensive SSRF assessment as standard.

Complete Functionality Mapping

Every application feature making server-side HTTP requests is identified and tested for SSRF. Testers map URL handling across the entire application rather than testing only obvious URL parameters.

Bypass Testing

When basic SSRF protections exist, testers systematically attempt IP encoding, redirect chains, DNS rebinding, URL parser inconsistencies, and protocol handler abuse. Protection validation goes beyond confirming basic blocklists exist.

Cloud Metadata Assessment

For cloud-hosted applications, SSRF testing specifically targets metadata service access across AWS, Azure, and GCP. Testing validates whether IMDSv2 enforcement, network controls, and application protections prevent credential theft through SSRF.

Zero False Positives

Every SSRF finding is confirmed through out-of-band interaction or direct response validation. Reports include exploitation evidence demonstrating exactly what the SSRF enables.

Beyond SSRF

SSRF testing integrates with comprehensive web application assessment covering OWASP Top 10 and beyond, API testing, and cloud security assessment. Application security assessment and offensive security testing provide end-to-end validation.

3-Week Delivery

Standard engagements deliver within three weeks. 90-day remediation support includes guidance on implementing SSRF prevention controls and complimentary retesting.

Ready for penetration testing that catches what scanners miss?

Contact AppSecure:

• Schedule Security Assessment
• Application Security Assessment
• Web Application Penetration Testing

Frequently Asked Questions

1. What is SSRF (Server-Side Request Forgery)?

Server-Side Request Forgery is a vulnerability where an attacker manipulates a server-side application into making HTTP requests to unintended destinations. The attacker provides a URL (or modifies a URL parameter) that the server fetches, targeting internal resources (databases, admin panels, metadata services) the attacker cannot reach directly from the internet. SSRF exploits the server's network position: the server can access internal infrastructure that the attacker cannot, and SSRF turns the server into a proxy to those internal resources.

2. Why is SSRF in the OWASP Top 10?

SSRF was added to the OWASP Top 10 (2021) as A10 because the vulnerability has become significantly more dangerous in cloud environments. Cloud instances have access to metadata services (169.254.169.254) containing temporary credentials, configuration data, and service tokens. SSRF targeting metadata services can expose cloud credentials enabling access to S3 buckets, databases, and other cloud resources. The Capital One breach demonstrated the catastrophic impact of SSRF in cloud environments, exposing 106 million customer records.

3. What is the difference between SSRF and CSRF?

SSRF (Server-Side Request Forgery) tricks the server into making requests to unintended destinations, using the server's network access to reach internal resources. CSRF (Cross-Site Request Forgery) tricks the user's browser into making requests to a legitimate application, using the user's authenticated session. SSRF affects server-side infrastructure access. CSRF affects client-side session abuse. SSRF targets internal services unreachable from outside. CSRF targets actions the authenticated user can perform.

4. How does SSRF exploit cloud metadata services?

Cloud providers (AWS, Azure, GCP) expose instance metadata through HTTP endpoints (169.254.169.254) accessible only from within the instance. SSRF allows an attacker to make the server request this metadata endpoint, retrieving instance identity, network configuration, and IAM/managed identity credentials. These credentials provide authenticated access to cloud services (S3, databases, Lambda functions) with whatever permissions the instance role grants. AWS IMDSv2 mitigates this by requiring token-based access, but applications using IMDSv1 remain vulnerable.

5. What is blind SSRF?

Blind SSRF occurs when the server makes the attacker-specified request but doesn't return the response content. The attacker cannot directly see what the server retrieved. Blind SSRF is detected through out-of-band techniques: the attacker provides a URL pointing to their own server and monitors for incoming requests confirming the target server made the request. Blind SSRF is still exploitable for internal port scanning (response timing reveals open/closed ports), triggering actions on internal services, and accessing cloud metadata where credentials are used internally.

6. How do attackers bypass SSRF protections?

Common bypass techniques include IP address encoding (decimal, hex, octal representations of blocked addresses), redirect chains (external URL that redirects to internal target), DNS rebinding (domain initially resolving to safe IP, then re-resolving to internal IP), URL parser inconsistencies (ambiguous URLs parsed differently by validator and HTTP client), protocol handler abuse (using gopher:// or file:// instead of http://), and IPv6 equivalents of blocked IPv4 addresses. Effective SSRF prevention requires validating resolved IP addresses rather than matching URL strings.

7. How can I prevent SSRF in my application?

Implement defence in depth with multiple layers. Layer 1: Input validation using allowlists of permitted destinations (strongest), blocklists of internal IP ranges and metadata addresses (supplementary), URL parsing with resolved IP validation, and protocol scheme restriction to http/https only. Layer 2: Network controls including egress filtering, AWS IMDSv2 enforcement, and network segmentation isolating application servers from sensitive services. Layer 3: Application architecture using dedicated request services with restricted network access, response content validation, and redirect following disabled or validated.

8. Can automated scanners detect SSRF?

Automated scanners detect basic SSRF patterns by injecting internal IP addresses into URL parameters. They consistently miss SSRF in webhook configurations, file import functionality, multi-step processes, PDF generation, document processing, and complex API interactions. Manual penetration testing identifies SSRF through complete functionality mapping, out-of-band interaction testing, systematic bypass testing, and application-specific analysis that scanners cannot perform.

9. What is the impact of a successful SSRF attack?

SSRF impact ranges from information disclosure to complete infrastructure compromise depending on what the server can access. Low impact: internal port scanning, service discovery. Medium impact: reading internal web pages, accessing configuration data. High impact: retrieving cloud credentials from metadata services. Critical impact: using retrieved credentials to access customer databases, modify infrastructure, or pivot through the internal network. The Capital One breach demonstrated critical impact: SSRF retrieving AWS credentials that accessed 106 million customer records.

10. How does penetration testing identify SSRF?

Professional penetration testers identify SSRF by mapping every application feature making server-side HTTP requests, testing each feature with internal addresses and out-of-band callbacks, systematically attempting bypass techniques against any protections present, and demonstrating maximum impact through controlled exploitation. Manual testing consistently discovers SSRF that automated scanners miss because SSRF often exists in application-specific functionality requiring human understanding of how the application processes URLs and external content.