Server-Side Request Forgery (SSRF)
SSRF is a vulnerability where an attacker tricks a server into making HTTP requests to unintended destinations, typically internal resources that are not directly accessible from the internet.
Understanding Server-Side Request Forgery (SSRF)
SSRF occurs when an application fetches a URL provided by the user and the server performs the request on the attacker's behalf. Unlike typical web requests originating from the user's browser, SSRF requests originate from the server, giving them access to internal network resources, cloud metadata endpoints, and services bound to localhost that are not exposed to the internet.
The most dangerous SSRF targets are cloud metadata services (e.g., http://169.254.169.254 on AWS, GCP, and Azure) which can expose IAM credentials, internal APIs and microservices that trust requests from the internal network, databases and caches that bind to localhost, and admin panels accessible only from the server's network.
SSRF comes in two forms. In standard SSRF, the attacker can see the response from the internal request. In blind SSRF, the attacker cannot see the response but can infer success or failure through timing, DNS lookups, or other side channels. Both are dangerous — blind SSRF can still be used to port-scan internal networks, access metadata services, or trigger actions on internal services.
Defenses include validating and restricting URLs to an allowlist of permitted domains, blocking requests to private IP ranges (10.x.x.x, 172.16-31.x.x, 192.168.x.x, 127.x.x.x, 169.254.x.x), using network-level controls to prevent the application server from accessing sensitive internal services, and disabling unnecessary URL schemes (file://, gopher://, dict://).
Why This Matters for Vibe-Coded Apps
SSRF risks appear in vibe-coded apps that include features like URL previews, webhook handlers, image proxy services, or "import from URL" functionality. When an AI generates a feature that fetches a user-provided URL on the server side, it typically does not add restrictions on what URLs can be fetched, creating an SSRF vulnerability.
If your vibe-coded app is deployed on a cloud platform like AWS, GCP, or Render, an SSRF vulnerability could expose cloud credentials through the metadata endpoint. Always validate user-provided URLs against a strict allowlist and block private IP ranges before making server-side requests.
Real-World Examples
Capital One Data Breach (2019)
A former AWS employee exploited an SSRF vulnerability in Capital One's web application firewall to access the AWS metadata service and obtain IAM credentials. These credentials were used to exfiltrate 106 million customer records, resulting in an $80 million fine.
GitLab SSRF via Webhooks
GitLab's webhook functionality allowed SSRF by accepting internal URLs as webhook destinations. Attackers could make the GitLab server send requests to internal services, metadata endpoints, and localhost ports, mapping the internal network and accessing sensitive resources.
Slack SSRF via File Upload
A researcher discovered that Slack's file sharing feature could be abused for SSRF. By providing an internal URL as a file source, the researcher could make Slack's servers fetch resources from internal networks and cloud metadata endpoints, potentially exposing sensitive infrastructure information.
Frequently Asked Questions
How does SSRF differ from CSRF?
CSRF tricks a user's browser into making requests to a target application. SSRF tricks the server itself into making requests to internal resources. CSRF exploits the user's authentication session, while SSRF exploits the server's network position and access to internal resources. SSRF is generally more severe because it can access internal infrastructure that is completely inaccessible from the internet.
Can SSRF access the cloud metadata endpoint?
Yes, and this is one of the most critical SSRF risks. Cloud platforms (AWS, GCP, Azure) expose metadata at http://169.254.169.254 which returns instance information, IAM credentials, and configuration. If your server can reach this endpoint, an SSRF vulnerability gives attackers temporary cloud credentials that may have broad permissions. AWS IMDSv2 mitigates this by requiring a PUT request with a token, but not all applications enforce IMDSv2.
Does URL validation prevent SSRF?
URL validation helps but is not sufficient alone. Attackers bypass URL validation using DNS rebinding (a hostname that resolves to an internal IP after validation), URL encoding tricks, IPv6 equivalents of private ranges, and redirects from allowed domains to internal targets. Robust SSRF prevention requires URL validation plus network-level controls (firewall rules preventing the application from accessing metadata endpoints and internal services directly).
What is blind SSRF?
Blind SSRF occurs when the attacker can make the server send requests to arbitrary destinations but cannot see the responses. While less immediately exploitable than full SSRF, blind SSRF can still be used to port-scan internal networks (detecting open ports via response timing), trigger actions on internal services that accept GET requests, exfiltrate data through DNS lookups to attacker-controlled domains, and access services that perform actions on any request regardless of the response.
Is Your App Protected?
VAS automatically scans for vulnerabilities related to server-side request forgery (ssrf) and provides detailed remediation guidance. Our scanner targets issues common in AI-generated applications.
Scans from $5, results in minutes. Get actionable fixes tailored to your stack.
Get Starter Scan