IM Engineer Study Notes
← Back to list
Security & Privacy
#SSRF#클라우드메타데이터#IMDSv2#egress통제#OWASP
Last updated · 2026-10-14

SSRF (Server-Side Request Forgery)

1. Overview

Definition: SSRF (Server-Side Request Forgery) is a vulnerability in which an attacker manipulates the URL or address parameter that a server application uses to fetch an external resource, forcing the trusted server to send a request on the attacker's behalf to an attacker-chosen internal network, cloud metadata service, or external endpoint. In effect, it degrades the server into the attacker's "proxy."

Modern applications make extensive use of features where the server fetches a resource from a user-supplied URL. Typical examples include webhook registration, remote image thumbnail generation, URL previews, PDF rendering, external API integration, and file import. In these flows the server trusts the URL handed to it and performs the request as-is; the problem is that the server sits at a trusted network position behind the firewall. Internal management ports, databases, and cloud metadata services that an external attacker cannot reach directly are freely accessible to the server. SSRF exploits exactly this structural weakness, letting the attacker "borrow" the server's trusted network position.

This "server fetches an external resource on the user's behalf" pattern is not confined to any one domain; it is virtually ubiquitous across modern services. Link-card previews on social networks, external image registration in shopping malls, file import in collaboration tools, external artifact downloads in CI/CD pipelines, and external URL lookups by chatbots and agents are all potential SSRF points. The more convenient a feature is, the more often it performs "the server goes out to an address the user specified," so SSRF is a textbook case of the security-convenience tension where feature expansion scales together with attack surface. Therefore SSRF should be treated not as a "feature to remove" but as a "feature pattern that must be designed safely."

The reason this threat rose to prominence is the spread of cloud and microservice architectures. In the on-premises single-server era internal resources were few, but in the cloud every instance can query temporary credentials (IAM role tokens) through a link-local metadata endpoint at 169.254.169.254. A single SSRF can now escalate directly into a full cloud takeover. Because of this severity, in its 2021 revision OWASP broke SSRF out for the first time as a standalone item, A10:2021 — Server-Side Request Forgery, reflecting a community survey that ranked first a threat previously buried under "Injection" or "Broken Access Control." From a Professional Engineer's perspective, the essence of SSRF should be seen not as a mere input-validation bug but as an architectural design flaw spanning trust boundaries, network segmentation, and least privilege.

Three features distinguish SSRF from other web vulnerabilities. First, asymmetric privilege abuse. The attacker has no privileges, but the server holds broad privileges on the internal network, so the attacker "amplifies" their own unprivileged state into the server's high-privileged state. Second, chaining. SSRF itself merely "makes the server send a request," but when metadata, internal Redis, or a management API sits at the other end, it leads to credential theft, remote code execution (RCE), and lateral movement. Third, a detection blind spot. The internal requests a server sends are hard to tell apart from legitimate traffic, and Blind variants in particular leave no response, making the attack hard to identify from logs alone. Because of these three features, SSRF is rated an "amplifying" threat whose real-world impact far exceeds the CVSS score of the standalone vulnerability.

2. Attack Structure and Threat Model

The key to understanding SSRF is the shift in "who sends the request." An ordinary attack has the attacker's own device throw packets directly at the target, but in SSRF a server with legitimate privileges fires the request on the attacker's behalf. As a result, internal resources that are closed from the outside are open in the server's eyes, and the firewall and network ACLs recognize the traffic as "internal communication sent by the server" and let it through.

Traditional perimeter security is built on the premise that "the outside is dangerous, the inside is safe." SSRF demolishes this premise, because an external attacker's intent is disguised as a trusted request originating from the inside. For this reason SSRF cannot be defended by perimeter firewalls alone, and it connects naturally with the zero-trust mindset discussed later — "even requests coming from the inside are verified and constrained by least privilege."

flowchart LR
    ATK(("Attacker")) -->|"crafted URL input"| APP["Web application server<br/>(trusted network position)"]
    APP -->|"legitimate external request"| EXT["Legitimate external resource"]
    APP -.->|"abused internal request"| META["Cloud metadata<br/>169.254.169.254"]
    APP -.->|"abused internal request"| INT["Internal services<br/>(DB·admin console·cache)"]
    APP -.->|"protocol switch"| FILE["file:// gopher://<br/>internal protocols"]
    META -.->|"IAM temporary credentials"| APP
    FW["Firewall / ACL"] -. "blocks external→internal" .-x ATK

The crux of the diagram above is that the firewall blocks the attacker's direct access (the dashed block line) but trusts and permits the requests the server sends inward. The attacker hijacks this trust merely by entering an internal address such as http://169.254.169.254/... into an input field. In other words, the impact of SSRF is proportional not to "what the server receives as input" but to "what the server can reach internally." Threat modeling must therefore first assess the application's egress rights and the sensitivity of adjacent internal resources.

Second, SSRF differs sharply by whether a response is returned. If the server returns the fetched content to the screen (In-band SSRF), the attacker can directly read the contents of internal resources. Conversely, even when no response comes back (Blind SSRF), the attacker can infer the existence of internal resources through side channels such as response-time differences, error messages, or whether a DNS lookup occurred, or can fire state-changing (write) requests against internal APIs. The detailed sequence below shows a typical attack flow targeting cloud metadata.

sequenceDiagram
    participant ATK as Attacker
    participant SRV as Application server
    participant IMDS as Metadata service (IMDSv1)
    participant S3 as Cloud storage
    ATK->>SRV: "image_url=http://169.254.169.254/latest/meta-data/iam/..."
    SRV->>IMDS: server issues the GET on its behalf
    IMDS-->>SRV: returns IAM role temporary credentials
    SRV-->>ATK: credentials exposed in response body
    Note over ATK: authenticate directly with the stolen keys
    ATK->>S3: access with valid credentials
    S3-->>ATK: sensitive data exfiltrated

What stands out in this flow is that the point of compromise is a single application input, yet the ultimate damage occurs irreversibly in an entirely different service (storage). Because a single vulnerability chains into privilege escalation and lateral movement, SSRF is classified as an "entry point" vulnerability.

To treat the threat model quantitatively, "the set of internal resources the server can reach" must be made explicit as the attack surface. For example, if one application server can reach 30 microservices in the same VPC, the metadata endpoint, an internal cache, and a log collector, then on a successful SSRF the attacker gains all 34 of those resources as potential targets. Conversely, if egress traffic is funneled through a single dedicated proxy and all other egress is blocked, then even the same SSRF shrinks the reachable resources to "destinations the proxy permits." In short, the real risk of SSRF is determined by network topology, not by code, and that is the starting point of threat modeling.

3. Attack Types

SSRF is divided into several types by the manner of response return, the target, and the protocol. Because each type differs in detection difficulty and response strategy, the distinction matters.

A. In-band (basic) SSRF. The server includes the content of the fetched external resource directly in its response. The attacker can see internal port-scan results, configuration files, or metadata credentials with their own eyes, making this the most immediate and dangerous form. It frequently occurs in URL preview and image proxy features.

B. Blind SSRF. The server performs the request but does not return the result in the response. The attacker sets up a collection server under their control (e.g., Burp Collaborator, a DNS-logging domain) and confirms the vulnerability by whether the server looks up or connects to that domain. They cannot read data directly, but it can be abused for state-changing API calls or internal network mapping.

C. Semi-blind SSRF. A type with no response body, inferring the existence or response of an internal service through indirect signals such as HTTP status codes, response time, or error messages. Internal port scanning that distinguishes whether a port is open by response latency is a representative case.

D. Protocol-switching SSRF. The attacker switches from http to schemes like file://, gopher://, dict://, or ftp:// to read local files or directly manipulate cleartext-protocol internal services (Redis, Memcached, SMTP). In particular gopher:// can send an arbitrary byte stream, making it the most destructive—injecting write commands into an unauthenticated internal Redis, for instance. This type goes beyond mere information disclosure to change the state of internal services, and under the right conditions can even lead to remote code execution (RCE), causing catastrophic outcomes in systems that do not strictly restrict allowed schemes.

Type Response returned Primary abuse Detection difficulty
In-band Yes (body) direct read of metadata·internal files Low
Blind No state-changing APIs·external-callback induction High
Semi-blind Partial (status·time) internal port scan·existence inference Medium
Protocol switch Case-by-case Redis·SMTP manipulation, file read Medium

This classification matters in practice because detection and response strategies differ by type. For In-band, where sensitive information rides in the response body, output filtering and response minimization are the first line of defense; but for Blind and semi-blind, egress control that stops the server from sending internal requests in the first place is the only reliable countermeasure. Protocol-switching types need the separate measure of restricting allowed schemes to http/https only and disabling the request library's support for non-standard schemes. Therefore, in penetration testing and code review, it is efficient first to classify "which SSRF type this feature is vulnerable to" and then map the matching defense.

4. Primary Targets and Bypass Techniques

The targets of SSRF are any resource that "the server can reach but the outside cannot." The first is the cloud metadata service seen earlier. AWS, GCP, and Azure all use 169.254.169.254, where one can query the temporary credentials of the IAM role assigned to the instance. The second is internal management interfaces—admin consoles not exposed externally, Kubernetes API servers, actuator endpoints, service discovery, and so on. The third is unauthenticated internal data stores (Redis, Elasticsearch, Memcached), which are especially vulnerable to protocol-switching SSRF when they use cleartext protocols.

The reason the defensive side cannot block this with simple denials is that bypass techniques are diverse. Attackers evade blacklists by transforming http://127.0.0.1 into http://127.1, octal/hex/integer notations (http://2130706433), or abbreviated IPv6 (http://[::1]). There is also DNS Rebinding, which changes the DNS response of an attacker-controlled domain to an internal IP right after validation; techniques that pass validation with a legitimate external URL and then redirect to an internal address via a 3xx response; and parser confusion attacks where the URL parser and the request library interpret @, #, or spaces differently. Thus a "string-level blacklist" cannot be a fundamental countermeasure, and the network-layer control discussed later is required.

Target Representative address/protocol What is sought
Cloud metadata 169.254.169.254 IAM temporary credentials
Internal management API 10.0.0.0/8, k8s API privilege escalation·config theft
Internal data store redis://, gopher:// data manipulation·RCE
Local files file:// reading config·secret keys

For example, if a financial mobile backend had a feature where the server directly downloads whatever "profile image URL" is entered, an attacker could put the metadata address in that field and obtain cloud credentials within seconds. In fact this pattern led to a massive breach in the case discussed below.

As another industry example, consider an e-commerce platform's product-registration feature where the server performs "fetch external product image." The attacker registers thousands of dummy products and, in each image URL, sequentially substitutes internal IP ranges (http://10.0.0.1~10.0.255.254), mapping the live hosts and open ports of the internal network from response-time differences alone. This is a textbook use of Blind SSRF as an internal reconnaissance tool, and it is dangerous because an internal structure invisible to external scans is exposed through a single application feature. In the bug-bounty ecosystem, too, SSRF can lead to metadata credential theft and so typically falls into the vulnerability class rewarded at high severity (High–Critical).

5. Comparison — SSRF and CSRF

CSRF (Cross-Site Request Forgery), despite the similar name, is fundamentally different in "who sends the forged request." CSRF makes the victim's (user's) browser carry the victim's authentication cookie to send the request the attacker wants, abusing client-side trust (the session). SSRF, by contrast, has the server itself send the request on the attacker's behalf, abusing the server's network position and privileges. Accordingly, CSRF defense focuses on "verifying the origin of the request," as with CSRF tokens and SameSite cookies, whereas SSRF defense focuses on "restricting the server's egress destinations." Failing to understand this difference leads to the wrong countermeasures (e.g., applying a CSRF token to SSRF).

This difference matters in practice because the locus of defensive responsibility differs. CSRF is resolved mainly at the application framework layer (token middleware, cookie attributes), whereas SSRF is incomplete with application input validation alone and is fundamentally blocked only when network/infrastructure-layer egress control is applied in parallel. In other words, if CSRF is the development team's homework, SSRF is a "cross-cutting" threat for which development, security, and infrastructure are jointly responsible—and that distinction separates the organizational implications of the two attacks.

The direction of impact also contrasts. CSRF hijacks actions within the privilege scope of an individual victim, so damage often stays at the level of a single user account. SSRF, by abusing the server's privileges, spreads across the infrastructure (credentials, internal services), and can therefore lead to a collapse of confidentiality across the system or organization. This very difference in reach is the core reason OWASP elevated SSRF to a standalone item.

Dimension SSRF CSRF
Request originator the server the victim's browser
Abused trust server's network position·privileges user session·cookie
Main damage internal-resource access·credential theft misuse of user privileges
Core defense egress control·allowlist CSRF token·SameSite

6. In Depth — Representative Case and Defensive Architecture

The most widely cited case is the 2019 Capital One data breach. According to published analyses, the attacker reached the EC2 metadata service (IMDSv1 at the time) through a misconfigured WAF (proxy) instance, obtained the temporary credentials of the IAM role assigned to the instance, and accessed roughly 100 million (approximately 100M in the US and 6M in Canada) customer records in an S3 bucket. For this incident Capital One was fined about USD 80 million by the U.S. Office of the Comptroller of the Currency (OCC) in 2020. That said, some academic analyses regard this as an open reverse-proxy abuse rather than SSRF, so it is more accurate to describe it in a balanced way as "widely cited as a representative SSRF case, though the root cause lies in proxy/privilege configuration flaws."

This incident became the catalyst for fundamentally changing defensive architecture. In November 2019 AWS introduced IMDSv2, which requires obtaining a session token first via a PUT request and then carrying it in a custom header (X-aws-ec2-metadata-token) on subsequent requests. A typical SSRF that only throws a plain GET cannot perform this preceding PUT step and is blocked. AWS also set a network hop-count limit on the metadata response (default 1), so that requests passing through a container or proxy cannot reach the metadata. This is a model case of solving the problem by "hardening infrastructure defaults" rather than "patching the application."

Other clouds have similar mitigations. GCP and Azure require mandatory custom request headers when querying metadata, such as Metadata-Flavor: Google and Metadata: true respectively. A simple URL-substitution SSRF struggles to attach such headers arbitrarily and is partially blocked, but when the attacker can also control the headers (e.g., an advanced SSRF that can forge the whole request), bypass is possible—so one must clearly recognize at design time that header requirements are only a supplementary control and do not replace egress blocking as the fundamental countermeasure. Because the details differ by cloud like this, in multi-cloud environments it is important to apply a common egress-control policy consistently from a central point.

Practical defense must be built not as a single measure but as defense-in-depth, always combining the application layer and the infrastructure layer. The main controls are as follows.

  • allowlist-based input validation: Since blacklists are neutralized by the notation variations and encodings seen earlier, design around an allowlist that passes only approved domains, IPs, and schemes (http/https). After parsing the URL, resolve the actual IP to be connected and explicitly reject private and link-local ranges (RFC 1918's 10/8, 172.16/12, 192.168/16, and 169.254.0.0/16).
  • Network-layer egress control (most powerful): Send the application's external egress only through a dedicated forward proxy, and block direct egress to metadata and internal ranges at the firewall, security group, or NetworkPolicy. Because this control works independently of code bypass techniques, it is close to a fundamental countermeasure.
  • Hardening cloud metadata: Enforce IMDSv2, limit the metadata hop count (default 1), and disable metadata on instances that do not need it, cutting off the credential-query path itself.
  • Least privilege: Narrow IAM roles and service accounts to the minimum needed for the feature, so that even if credentials are stolen, the privileges and impact the attacker gains are limited.
  • Guarding against redirects and DNS rebinding: Turn off or re-validate automatic following of 3xx redirects on external requests, and pin the resolved IP for the connection to prevent the TOCTOU (rebinding) in which the IP differs between the time of validation and the time of connection.
  • Response minimization: Do not expose the raw content or error messages of fetched external resources to the user as-is, reducing In-band disclosure and semi-blind inference.

Detection and response must also be part of the design. Because SSRF—especially the Blind type with no response—is hard to identify from logs alone, it is effective to correlate "events where the application server attempted abnormal egress to internal ranges or the metadata endpoint" from egress-proxy and firewall logs and to alert on them via a SIEM. In particular, access attempts to 169.254.169.254 almost never occur in legitimate application traffic, so they can serve as a high-confidence detection signature. In penetration testing, use an external callback-collection server to actively validate even Blind SSRF.

On the standards/framework side, SSRF is classified as CWE-918 (Server-Side Request Forgery), and OWASP presents concrete checklist items such as allowlists, IP validation, and scheme restriction through its testing guide and cheat sheets. Organizations should reflect these in their own secure-coding standards and code-review checklists and make "does the server fetch an external URL" a mandatory question in threat modeling at the design stage of new features, controlling the risk by up-front design rather than after-the-fact patching.

7. Considerations and Implications (Professional Engineer's Perspective)

Reduced to a "one-line input-validation bug," SSRF recurs again and again; elevated to a problem of trust boundaries and network topology, it can be controlled systematically. From a Professional Engineer's perspective, the following five points must be weighed in balance.

  • Application strategy: SSRF must be approached as a trust-boundary redesign, not a single code fix. Identify as assets all features where the server fetches an external URL (webhooks, importers, previews), and establish a "secure by default" scheme that applies an allowlist and a dedicated egress proxy to each feature.
  • Trade-off: Strict allowlists and egress blocking raise security but reduce the flexibility of legitimate external integrations. Conversely, allowing arbitrary URLs for convenience enlarges the attack surface. Organizations must codify as policy the balance point between "scope of allowance" and "operational agility" according to each feature's risk level.
  • Outlook: As serverless, containers, and service meshes spread, internal communication grows exponentially and so does the SSRF attack surface. Alongside cloud providers' hardening of metadata defaults (enforcing IMDSv2), workload identity (short-lived, per-workload tokens) and zero-trust-based egress control are expected to become the standard.
  • Related technologies: SSRF defense is tightly linked with zero trust (ZTNA), network segmentation (microsegmentation), workload identity (SPIFFE/SPIRE), and cloud security posture management (CSPM). In particular, egress control is most effective when designed together with data loss prevention (DLP).
  • Governance: Because SSRF is an area where development, security, and infrastructure responsibilities intersect, always include an "external-URL-fetching feature" item in SSDLC threat modeling and code-review checklists, and be sure to include Blind SSRF detection in penetration-test scenarios.
  • Supply-chain / third-party considerations: Not only code you wrote but also third-party components—image-processing libraries, PDF generators, document converters, headless browsers—can become SSRF paths if they internally fetch URLs. Therefore identify "components that make external requests" in the dependency inventory (SBOM) and bring them, too, within the scope of egress control.
  • Measurement and improvement: Manage the maturity of SSRF response with quantitative metrics such as "share of features with an allowlist applied," "egress-blocking coverage," and "IMDSv2 enforcement rate," and establish a PDCA cycle that feeds back red-team exercise results to continuously strengthen the controls.

References

In one line: SSRF is an architectural flaw that turns a trusted server into the attacker's proxy to reach internal networks and cloud metadata, and it must be countered with layered, infrastructure-default defenses—allowlists, egress control, least privilege, and IMDSv2—rather than blacklists.