Server Side Request Forgery: The Quiet Killer in SaaS Integrations

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 user-provided URLs 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 user-controlled URLs. 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 user-triggered HTTP fetches in an isolated environment without internal network access. This combination is the only approach that addresses the full attack surface.

Common mistakes

1. Validating the URL only at parse time before DNS resolution. The hostname in a user-provided URL 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.

1. 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 user-provided URLs.

1. Allowing arbitrary URL schemes in user-provided URLs. 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.

1. 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 network-segmented container that cannot access the production database directly. This principle of least privilege limits the impact of successful SSRF.

1. 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

1. Audit all features that make outbound HTTP requests to user-controlled URLs. 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.

1. 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.

1. 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.

Related reading

• Secrets Management for SaaS: Vault, AWS Secrets Manager, Doppler
• Secrets in CI: The Patterns That Avoid Leaks
• SQL Injection in 2026: Still Happening, Still Preventable
• Right to Be Forgotten: How to Implement It Without Pain