URLを入れるとその中身を取ってくる、というありふれた便利機能が、最悪の場合クラウドの認証情報を奪われる原因になります。これがSSRFです。仕組みと防御をゼロから解説します。
何が起きているのか
普通のアクセスは「利用者 → 外部サイト」。SSRFは、サーバーに代わりにアクセスさせて、内部の宛先に届かせます。サーバーは外部から見えない内部ネットワークや、クラウドの認証情報提供先にアクセスできるため、そこを間接的に読まれてしまいます。
169.254.169.254（クラウド認証情報）クラウドでは、この内部宛先（メタデータ提供先）から 一時的な認証情報が取れることがあります。SSRFでそこに到達されると認証情報を奪われ、ストレージ全体の持ち出しにつながります。これは実際に大規模事故になりました。→ Capital One — SSRFから1億人分が漏れた話
どこに潜むか
「ユーザーが入れたURLをサーバーが取りに行く」機能はすべて候補です。
| 機能 | ありがちな実装 |
|---|---|
| OG/リンクプレビュー生成 | 貼られたURLをサーバーが取得してサムネ生成 |
| Webhook送信 | ユーザー指定の宛先へサーバーがPOST |
| 画像・ファイル取り込み | 「URLから画像を取得」 |
| サイト診断ツール | 入力されたサイトにサーバーがアクセスして検査 |
検証で見落としやすい点
「内部IPを弾けばOK」では不十分です。次のような回避方法にも対策が必要です。
単純なブロックでは漏れる
- リダイレクト追従：許可ドメインが
302で内部アドレスへ飛ばす。 - DNS再解決（rebinding）：検証時は外部IP、取得時に内部IPへ切り替わる。
- IP表記の揺れ：10進・8進・短縮表記などで内部アドレスを偽装。
- 別スキーム：
file://やgopher://など想定外のスキーム。
機能を作る側の防御
SSRFは「機能の作り方」で防ぎます。当サイトがセキュリティ製品として自分の診断機能に課しているルールでもあります。
宛先を許可リスト方式に
スキーム（http/https）とホストを許可したものだけに限定。「内部を弾く」より「許可したものだけ通す」ほうが確実。
内部宛を遮断
127.0.0.1 / 10.x / 192.168.x / 169.254.169.254（メタデータ）等への到達を拒否。
所有確認したドメインだけ（診断系）
利用者が所有を証明したドメインのみを対象にする。第三者サイトにアクセスさせない。
回避経路とメタデータを保護する
リダイレクトの最終到達先も検証、DNS再解決を考慮。クラウドは IMDSv2 等でメタデータをトークン必須にする。
当サイトは「秘密を預からない」「所有確認したものだけ診断」「被害が及ぶ範囲を最小化」を設計の基本にしています（→ 当サイトについて）。
SSRF・CSRF・オープンリダイレクトの違い
どれも「行き先を外から指定される」問題ですが、動くものと届く範囲が違います。
| 攻撃 | 誰がどこへ行くか | 届く範囲 |
|---|---|---|
| SSRF | あなたのサーバーが、指定された宛先へリクエストを送る | 内部ネットワーク、クラウドの認証情報など、外から届かない場所 |
| CSRF | 利用者のブラウザが、本人の意図しないリクエストを送る | その利用者がログインしているサイトで、本人ができる操作 |
| オープンリダイレクト | 利用者のブラウザが、指定された外部サイトへ転送される | 偽サイトへの誘導（フィッシング） |
SSRFが特に危険なのは、届く範囲が「サーバーの内側」だからです。ファイアウォールで外から守っている場所にも、サーバー経由なら届いてしまいます。
具体例：フレームワークの便利機能にも潜む
SSRFは、自分で書いた「URL取得機能」だけでなく、使っているフレームワークの機能にも出ます。たとえばNext.jsの近年のCVEでは、外部URLの画像を取り込む画像最適化などのサーバー機能でSSRF（CWE-918）が上位に入っています（→ Next.js・Reactの脆弱性の実データ）。MITREが2025年12月に公表した「CWE Top 25」（危険なソフトウェアの弱点の上位25）でも、SSRFは22位に入っています。
クラウドの例では、Capital Oneの事故が代表です。SSRFでメタデータ提供先に届き、過剰な権限を持つ一時的な認証情報が奪われました。AWSは2019年11月、この種の被害を減らすためにIMDSv2を公開しています。
自分の環境で確認する方法
URLを受け取って取りに行く箇所を一覧にする
ソースコードで、HTTPクライアント（fetch・axios・requests など）の宛先に利用者の入力が入る箇所を探す。リンクプレビュー、Webhook、画像の取り込み、PDF生成、インポート機能が典型。
フレームワークの許可設定を確認する
画像の最適化や外部取り込みの設定で、取りに行ってよいホストを広く許可していないかを見る（Next.jsなら images.remotePatterns にワイルドカードだけの指定がないか）。
IMDSv2を必須にする（AWS）
EC2インスタンスのメタデータ設定で、HttpTokens が required（IMDSv2のみ受け付ける）になっているかを確認する。コンテナを使わないサーバーでは、トークンの応答が届く範囲（ホップ数の上限）を1のままにしておく。
サーバーの外向き通信を絞る
URLを取りに行く処理は、内部ネットワークへ通信できない専用の環境で動かすか、外向き通信を必要な宛先だけに制限する。アプリ側の検証が漏れても、ネットワークで止められる。
出典（一次情報）
- OWASP「Server-Side Request Forgery Prevention Cheat Sheet」 — cheatsheetseries.owasp.org（許可リスト、内部アドレスの遮断、リダイレクトとDNSの扱い）
- AWS「Use the Instance Metadata Service to access instance metadata」 — docs.aws.amazon.com（IMDSv2のセッショントークン、required 設定、ホップ数の上限）
- AWS Security Blog「Add defense in depth against open firewalls, reverse proxies, and SSRF vulnerabilities with enhancements to the EC2 Instance Metadata Service」（2019年11月） — aws.amazon.com
- Microsoft「Azure Instance Metadata Service」 — learn.microsoft.com（Azureも 169.254.169.254 を使う）
- MITRE「2025 CWE Top 25 Most Dangerous Software Weaknesses」（2025年12月） — cwe.mitre.org（CWE-918 が22位）
次に読む
分類番号
CWE は脆弱性の原因となる弱点の種類を、MITRE ATT&CK は攻撃者の手口を分類した番号体系です。どちらも MITRE が管理し、脆弱性情報や検知ルールの分類に広く使われています。
CWE™: Copyright © 2006–2026, The MITRE Corporation. CWE is a trademark of The MITRE Corporation. The MITRE Corporation hereby grants you a non-exclusive, royalty-free license to use CWE for research, development, and commercial purposes. Any copy you make for such purposes is authorized on the condition that you reproduce MITRE’s copyright designation and this license in any such copy. CWE Terms of Use
よくある質問
Qどんな機能でSSRFが起きやすい？
『ユーザーが入れたURLをサーバーが取りに行く』機能です。OGプレビュー生成、Webhook送信、画像取り込み、サイト診断ツールなど。便利機能ほど注意が必要です。
QなぜSSRFはクラウドで特に危険？
クラウドの仮想マシンには内部限定の『メタデータ提供先』があり、そこから一時的な認証情報が取れることがあるためです。SSRFでそこに到達されると認証情報を奪われ、ストレージ全体の持ち出しにつながります（Capital One事故の経路）。
QSSRFをどう防ぐ？
宛先を許可リストで厳格に検証し、内部IP（127.0.0.1、10.x、169.254.169.254 等のクラウドメタデータ）への到達を遮断します。診断系なら『所有を確認したドメインだけ』に限定し、リダイレクト追跡やDNS再解決による回避も防ぎます。
QSSRFとCSRFの違いは？
リクエストを送る主体が違います。CSRFは利用者のブラウザに、本人が意図しないリクエストを送らせる攻撃です。SSRFはあなたのサーバーに、本来アクセスさせたくない宛先へリクエストを送らせる攻撃です。CSRFの被害はその利用者の権限の範囲、SSRFの被害はサーバーが届く範囲（内部ネットワークやクラウドの認証情報）に及びます。
QIMDSv2にすればSSRFは防げる？
クラウドの認証情報を奪われる経路は大きく狭まりますが、SSRFそのものは防げません。AWSのIMDSv2は、PUTで取得したセッショントークンがないとメタデータを返さないため、URLを取りに行くだけの単純なSSRFでは認証情報に届きにくくなります。一方、社内の管理画面や内部APIへの到達は別問題なので、宛先の許可リストと内部宛の遮断は必要です。
Q169.254.169.254 とは？
クラウドの仮想マシンが、自分の設定や一時的な認証情報を取得するための内部専用アドレスです（リンクローカルアドレス）。AWS・Azure・Google Cloud などが同じアドレスを使っています。外からは届きませんが、サーバー自身からは届くため、SSRFで最も狙われやすい宛先です。