Server Side Request Forgery: The Quiet Killer in SaaS Integrations
Server Side Request Forgery (SSRF) is a vulnerability where an attacker can cause the server to make HTTP requests to a destination the attacker controls, which may include internal network resources, cloud provider metadata services, or other backend infrastructure not accessible from the public internet. SSRF is particularly dangerous in SaaS products that accept URLs provided by users (webhook endpoints, image imports, integration callbacks, RSS feed fetchers) because the server's network position grants access to resources the attacker cannot reach directly.
What you need to know
- SSRF lets attackers use your server as a proxy to reach internal resources, including the AWS metadata service that exposes IAM credentials.
- Any feature that fetches URLs provided by users is an SSRF vector: webhooks, image imports, link previews, integration callbacks.
- Basic URL validation (blocking private IP ranges) is necessary but insufficient. DNS rebinding bypasses validation performed at parse time.
- Enable AWS IMDSv2 on all EC2 instances. This is the most impactful single mitigation for SSRF in AWS environments.
- Defense in depth: combine URL validation, network egress controls, and isolated fetch environments.
The core argument
SSRF is categorized as a high severity vulnerability in the OWASP Top 10 because the impact is not limited to data disclosure. Successful SSRF against a cloud hosted application can yield IAM credentials with significant AWS permissions, which translates to the attacker having cloud infrastructure access: reading S3 buckets, querying databases, escalating to administrative privileges. The attack path from SSRF to full cloud compromise is well documented and has been used in several high profile breaches.
The reason SSRF is particularly prevalent in SaaS products is that SaaS features are built around integrations. Webhook endpoints, third party data imports, link preview generation, custom integration callbacks: these features are core to the SaaS value proposition and all involve the server making outbound HTTP requests to URLs the user controls. The same feature that makes the product useful is the attack surface.
The prevention complexity is real. Simple IP validation does not prevent DNS rebinding. Allowlisting does not scale when the product integrates with any external service the customer chooses. The correct approach is layered: validate URLs before and after resolution, enable cloud provider metadata service protections (IMDSv2), enforce network egress controls that prevent requests to internal ranges, and consider running HTTP fetches triggered by the user in an isolated environment without internal network access. This combination is the only approach that addresses the full attack surface.
Common mistakes
Validating the URL only at parse time before DNS resolution. The hostname in a URL provided by a user resolves to an IP address at request time, not at validation time. An attacker can control a domain that passes validation (public IP) and then redirect to an internal IP (DNS rebinding) after validation passes. Validate the final resolved IP immediately before making the request, not the URL string.
Not enabling IMDSv2 on AWS EC2 instances. AWS IMDSv2 requires a two step process to obtain credentials from the metadata service, which prevents the simple GET based SSRF attack against
169.254.169.254. Enabling IMDSv2 (and optionally disabling IMDSv1 entirely) is a configuration change in the EC2 instance settings or the Terraform/CloudFormation template. This should be enabled on every EC2 instance that runs application code that fetches URLs provided by users.Allowing arbitrary URL schemes in URLs provided by users. Validation that only checks for private IP addresses but allows any URL scheme can be bypassed with file:// (local file access), gopher:// (protocol with raw TCP capabilities), or dict:// (port scanning). Validate that the scheme is http or https before any other validation. Reject all other schemes.
Running URL fetch operations with production database credentials. The blast radius of an SSRF vulnerability that succeeds in exfiltrating credentials depends on what credentials the compromised process has access to. URL fetch operations should run in a context with minimal credentials: a separate service role, an isolated Lambda function, or a container segmented off the network so it cannot access the production database directly. This principle of least privilege limits the impact of successful SSRF.
Not logging outbound HTTP requests from application servers. SSRF attacks are often detectable through outbound request logs: unusual hostnames, requests to IP addresses in private ranges, or requests to the metadata service endpoint. Without outbound request logging, SSRF attacks may go undetected until the consequences become visible. Log all outbound HTTP requests with the destination host, resolved IP, and response status.
Where to start
Audit all features that make outbound HTTP requests to URLs users control. Create an inventory of webhook registration, link preview, import from URL, and integration callback features. For each, verify that URL validation is in place and that the validation checks the resolved IP after DNS resolution, not just the URL string.
Enable IMDSv2 on all production EC2 instances today. This is a one command AWS CLI change per instance or a Terraform variable change for infrastructure as code deployments. It is the single highest impact SSRF mitigation for AWS environments and requires no application code changes.
Implement outbound request logging and add an alert for requests to RFC 1918 private address ranges. Log every outbound HTTP request made by application servers including the destination IP (resolved, not just the hostname). Add a security alert for any request to 10.x.x.x, 172.16.x.x, 192.168.x.x, or 169.254.x.x from production application processes. This alert catches both successful and attempted SSRF attacks.
FAQ
Frequently asked
- What are common SSRF attack vectors in SaaS products?
- What can an SSRF attacker access that makes it dangerous?
- How do you validate URLs provided by users to prevent SSRF?
- What is DNS rebinding and why does it bypass basic SSRF protections?
- What defense in depth measures reduce SSRF risk beyond URL validation?
Author
About me and why that should matter to you
Yashveer Singh. Full stack developer. Founder of Yashveer Labs. Based in New Delhi. The reason it should matter to you is that most engineers writing about this topic have not actually done it. I have. The code is on GitHub. The systems are on real URLs. The portfolio has the proof. The contact channel is Instagram. If the work needs to get done, that is how you reach me.