The one-sentence version
Many features require the server to "access a URL provided by a user": link previews, importing images, calling Webhooks, or AI web browsing tools. Without restrictions, an attacker can provide an internal address, making the server access things that outsiders normally cannot reach. This is called Server-Side Request Forgery (SSRF).
In cloud environments, the most dangerous target is the cloud metadata interface (169.254.169.254): accessing it allows one to obtain the temporary cloud credentials of that server. In 2019, the Capital One data breach involving approximately 100 million customers was driven by this key step.
This article has three layers:
- Layer 1: The Intuition: Asking the receptionist to get something from the server room for you
- Layer 2: Real-World Use: The Capital One incident, link previews, AI browsing tools
- Layer 3: Principles and Engineering details
Layer 1: The Intuition
1.1 Asking the receptionist to get something from the server room for you
A company's receptionist offers a service: "Give me an address, and I will go pick up the package for you." Outsiders cannot enter the company's internal premises, but the receptionist can.
If the receptionist does not check the address, someone might say: "Please go to the server room on the third floor and get that file off the server." The receptionist does as told.
The server is like this receptionist. It is usually located within the intranet and can access databases, management backends, and internal cloud platform interfaces—things that outsiders cannot access directly.
1.2 Why it is becoming more common
Features where "the server accesses a URL on behalf of the user" are increasing:
- Link previews in social and chat software;
- "Import from URL" for images and files;
- Webhook callbacks;
- PDF generation (rendering an HTML that contains external resources);
- AI Agent web browsing and scraping tools.
Layer 2: Real-World Use
- Capital One (2019): An attacker exploited an SSRF vulnerability in a misconfigured Web Application Firewall to access the AWS Instance Metadata Service, obtaining temporary credentials for that instance's role; this role had excessive permissions, allowing the reading of many S3 buckets. Ultimately, data of approximately 100 million US customers and 60 million Canadian customers was stolen. Following this incident, AWS introduced IMDSv2, a metadata service that requires a token.
- A regular in bug bounties: SSRF is one of the most common high-severity vulnerabilities in major company bug bounty programs, frequently appearing in features like image proxies, link previews, file imports, and Webhooks.
- AI Tools: Services that provide "web scraping" tools for AI must defend against SSRF if they run within an intranet or cloud environment; otherwise, a user (or a model subject to prompt injection) could trick the tool into accessing metadata interfaces and internal services.
Layer 3: Principles and Engineering
3.1 Common Targets
| Target | Consequence |
|---|---|
Cloud Metadata Interface 169.254.169.254 |
Obtaining temporary cloud credentials for the instance, user data scripts |
Management ports on localhost / 127.0.0.1 |
Accessing management interfaces, databases, or caches open only to localhost |
| Other internal services | Internal APIs, monitoring dashboards, CI systems |
File protocol file:// |
Reading local files from the server |
3.2 Common Bypass Techniques (to be considered during defense)
| Technique | Description |
|---|---|
| Alternative IP representations | Decimal, octal, and IPv6 mapped addresses can all point to 127.0.0.1 |
| Redirection | First accessing a legitimate external address, which then performs a 302 redirect to an internal address |
| DNS Rebinding | A domain returns a legitimate external IP during the first resolution (passing checks) and an internal IP during the second resolution (the actual request) |
| Parsing discrepancies | The code that validates the URL and the code that actually makes the request parse the URL differently |
Therefore, "checking if the URL string contains localhost" is far from enough.
3.3 Defense Checklist
| Layer | Measure |
|---|---|
| Network | Place services that initiate external requests in an isolated network zone so they cannot access the intranet or metadata interfaces at the network level (most reliable, see "Egress Control") |
| Post-resolution validation | Resolve the domain to an IP first, use that IP to make the request, and check that it is not in private, loopback, or link-local address ranges |
| Redirection | Prohibit automatic redirection following, or re-validate every jump |
| Protocol | Only allow http / https |
| Cloud Metadata | Enforce IMDSv2 (requires first obtaining a token via a PUT request, which is difficult for standard SSRF); disable it if not needed; block it within containers |
| Least Privilege | Grant only the necessary permissions to the instance role so that if an SSRF is successful, the damage is limited (see "Least Privilege and Key Management") |
| Response | Do not return the raw scraped content (especially error messages) directly to the user |
3.4 Special Reminder for AI Tools
In addition to defending against SSRF, AI web tools must consider: the scraped content may contain injection instructions (see "Indirect prompt injection"), and the model may be guided to access an address specified by an attacker (see "Markdown image data leakage"). The best practice is to run the scraping service in an isolated environment that can only access the public internet and has no access to the intranet.
Summary
| Layer | Key points |
|---|---|
| Intuition | Asking the receptionist to get something from the server room for you |
| Most dangerous target | Cloud Metadata Interface: obtaining temporary credentials (Capital One) |
| Bypass | IP transformation, redirection, DNS rebinding, parsing discrepancies |
| Defense | Network isolation is most reliable; validate by IP after resolution; IMDSv2; least privilege |