SSRFとは、Webアプリケーションのサーバーを悪用し、攻撃者が指定した宛先へリクエストを代理送信させる脆弱性です。ユーザーが渡したURLをサーバーが検証せずに使うと、攻撃者はその宛先を内部システムに書き換えられ、本来アクセスできないリソースへ到達させられます。危険なのは、この攻撃がファイアウォールの内側にある社内システムやクラウドの認証情報にまで届いてしまうためです。実際に、1億人を超える個人情報が漏えいした米国の事件でもSSRFが関与しました。この記事では、SSRFの仕組みと攻撃の流れ、脆弱性が生まれる原因、そしてOWASPが推奨する正しい対策までを、開発や運用の現場で確認すべき観点とあわせて説明します。
SSRFは、Webアプリケーションが外部のURLを受け取ってサーバー側でアクセスする仕組みを悪用し、攻撃者が指定した宛先へリクエストを送らせる脆弱性です。ユーザーが渡したURLをアプリケーションが検証せずに使うと、攻撃者はその宛先を内部システムに書き換えられます。結果として、外部からは直接触れないはずのリソースに、信頼されたサーバーを踏み台にしてアクセスされてしまいます。まずは定義と、その深刻度を示す位置づけから見ていきます。
SSRFを一言でいうと、サーバーに「おつかい」を悪用させる攻撃です。多くのWebアプリケーションには、ユーザーが入力したURLの画像を取得したり、外部APIと連携したりする機能があります。この「指定された先にアクセスしてくる」動きそのものを乗っ取るのがSSRFです。
たとえば、プロフィール画像のURLを受け取ってサーバーが取得する機能があるとします。本来は外部の画像置き場を指すはずのURLに、攻撃者が社内サーバーのアドレスを入力します。アプリケーションがその宛先を確かめないと、サーバーは言われるまま内部にアクセスし、応答を攻撃者に返してしまいます。攻撃者自身は内部に入れなくても、内部にいるサーバーを操って情報を持ち出せる点が、この脆弱性の本質です。
入口となるのは、フォームに直接入力するURLだけではありません。Webhookの通知先設定、URLを指定してのファイル取り込みやPDF生成、リンクプレビューの生成など、アプリケーションがサーバー側でURLにアクセスする機能はすべて対象になり得ます。
SSRFは、Webアプリケーションの代表的なセキュリティリスクをまとめた「OWASP Top 10」の2021年版で、10番目の項目「A10」として新たに追加されました（※1）。OWASP（Open Web Application Security Project）は、Webアプリケーションのセキュリティ向上に取り組む非営利団体で、そのTop 10は開発者やセキュリティ担当者にとって事実上の標準として参照されています。
その後、2025年11月に発表され2026年1月に正式リリースされた2025年版では、SSRFは独立したカテゴリではなくなり、1位である「A01:2025 - Broken Access Control（アクセス制御の不備）」に統合されました（※2）。細工したリクエストによって本来アクセスできないリソースへ到達させるというSSRFの性質が、アクセス制御の不備の一種であると判断された結果です。
注意したいのは、これが「SSRFの重要性が下がった」という意味ではない点です。独立した10位から、最上位カテゴリを構成する要素へと位置づけが変わったと読むべきものです。
A01:2025のページでは、このカテゴリを代表するCWEの一つとしてCWE-918（SSRF）が明記されており、対象から外れたわけではありません（※3）。OWASPは2021年版の時点で、外部URLを取得する機能が現代のWebアプリケーションで一般的になったこと、そしてクラウドサービスの普及とアーキテクチャの複雑化により被害が深刻化していることを、SSRF増加の背景として挙げていました（※1）。この状況は現在も変わっていません。
※1 参考：OWASP│A10 Server Side Request Forgery (SSRF) - OWASP Top 10:2021
※2 参考：OWASP│「OWASP Top 10:2025」
※3 参考：OWASP│「A01 Broken Access Control - OWASP Top 10:2025」
SSRFが深刻なのは、攻撃が「内部に届く」ためです。多くの防御は、外部と内部の境界にファイアウォールを置き、外からの直接アクセスを遮断する考え方に立っています。ところがSSRFは、その境界の内側にいるサーバーを経由するため、境界防御を正面から破らずに迂回します。ここでは、迂回の怖さ、クラウド特有の被害、そして実際に起きた事件の順に見ていきます。
SSRFのリクエストは、攻撃者からではなくサーバーから発信されます。ファイアウォールやアクセス制御は、外部からの通信を止めるようには設定されていても、内部のサーバーが内部の別システムにアクセスする通信は許可していることが少なくありません。攻撃者はこの信頼関係を突き、サーバーを踏み台にして内部を探ります。
OWASPは、SSRFによって攻撃者が内部サーバーのポートスキャンを行い、ネットワーク構成を把握したり、「file:///etc/passwd」のような指定でローカルファイルや内部サービスの情報を読み出したりするシナリオを挙げています（※1）。境界の内側は外部より防御が手薄なことが多く、いったんそこへ到達されると被害が連鎖しやすくなります。
クラウド環境では、SSRFによって認証情報そのものが盗まれる危険があります。代表的な標的が、AWSのEC2インスタンスが持つメタデータ取得の仕組みであるIMDS（Instance Metadata Service）です。IMDSは、リンクローカルアドレス（169.254.169.254）で接続され、インスタンスの情報のほか、割り当てられたIAMロールによるAWS認証情報を取得できます（※2）。
問題は、旧方式のIMDSv1が単純なリクエスト・レスポンス方式である点です（※2）。SSRFでこのアドレスへリクエストを送らせれば、攻撃者は認証情報を抜き取り、それを使ってデータ保管サービスなど他のクラウドリソースにアクセスできます。内部への「到達」が、そのまま「なりすまし」に直結する構図です。
SSRFの危険性は、現実の大規模事件でも示されています。2019年、米金融大手のCapital Oneで不正アクセスが発生し、米国で約1億人、カナダで約600万人分の個人情報が漏えいしました。設定に不備のあったWAF（Web Application Firewall）が突かれ、SSRFによってEC2のメタデータからIAMロールの認証情報が取得され、最終的にクラウド上の保管データが持ち出されたとされています。防御機構であるはずのWAFそのものが踏み台にされた点が、この事件の特徴です。
漏えいした情報には、クレジットカードの申込情報などが含まれていました。この事件を機に、後述するIMDSv2の導入が広く進むことになりました。単なる理論上のリスクではなく、大企業でも一度突かれれば桁違いの被害につながる、という事実がここから読み取れます。
※1 参考：OWASP│A10 Server Side Request Forgery (SSRF) - OWASP Top 10:2021
※2 参考：Amazon Web Services│IMDSv2 の使用 - Amazon Elastic Compute Cloud
SSRFを防ぐには、どう攻撃され、なぜ脆弱性が生まれるかを理解しておく必要があります。攻撃の流れはシンプルですが、原因となる実装のミスにはいくつかのパターンがあります。さらに、単純な検証では防ぎきれないすり抜けの手口も存在します。順に見ていきます。
SSRF攻撃は、大きく3段階で進みます。まず攻撃者が、宛先を内部システムに書き換えた細工済みのリクエストを送ります。次に、脆弱性のあるサーバーが、その宛先を検証しないまま本来アクセスできない内部サーバーへリクエストを送ります。最後に、内部からの応答がサーバーを経由して攻撃者に返り、内部の情報が漏れます。
この流れの要点は、攻撃者と内部システムのあいだに、常に「信頼されたサーバー」が挟まっていることです。サーバーが攻撃者の代理として動くため、通信ログ上は正規のサーバーからのアクセスに見え、検知が難しくなります。
SSRFの根本原因は、ユーザーから受け取ったURLを検証せずにサーバー側のリクエストへ使うことです。OWASPは、Webアプリケーションがユーザー提供のURLを検証せずに外部リソースを取得するときにSSRFが発生する、と定義しています（※1）。
たとえば、フォームで受け取ったURLをそのままサーバーの取得処理に渡す実装では、そのURLが外部の正当なサイトなのか、内部アドレスなのかを区別していません。入力を信頼してしまうこの前提が、攻撃者に宛先を自由に指定する余地を与えます。
検証を入れていても、単純なチェックはすり抜けられることがあります。まず注意したいのが、いったん許可された外部サイトへアクセスさせ、そこから内部アドレスへリダイレクトさせる手口です。OWASPは、こうしたバイパスを防ぐため、Webクライアント側でリダイレクトの追従を無効にするよう推奨しています（※2）。
もう一つが、DNSの名前解決を悪用するDNSリバインディングと呼ばれる手法です。これは、検証の時点では正当な外部アドレスを返し、実際のアクセス時に内部アドレスへ切り替える攻撃で、URL文字列のチェックだけでは防げません（※2）。攻撃者は正規のドメイン名を内部IPアドレスに紐づけられるため、ドメイン名だけを確認する検証は破られます。これらの存在が、次章で述べる「拒否リスト頼み」が危険とされる理由につながります。
※1 参考：OWASP│A10 Server Side Request Forgery (SSRF) - OWASP Top 10:2021
※2 参考：OWASP│Server Side Request Forgery Prevention Cheat Sheet - OWASP Cheat Sheet Series
SSRFの対策は、複数の防御を組み合わせる多層防御が前提です。ただし、その中でも「やってはいけない対策」と「中心に据えるべき対策」がはっきり分かれます。ここでは、OWASPの推奨に沿って、避けるべき方法から順に説明し、最後に対策全体を表でまとめます。
まず避けたいのが、危険な宛先を列挙して弾く拒否リスト（deny list）や、正規表現によるパターンチェックだけに頼る方法です。OWASPは、拒否リストはバイパスされやすいため、許可リストを優先すべきだと述べています（※1）。理由は、攻撃者が回避用のパターンリストやツール、技術を豊富に持っており、列挙型のチェックはすり抜けられるためです（※2）。
前の章で触れたリダイレクトやDNSリバインディングは、まさに拒否リストや単純なパターンマッチをかいくぐる手口です。「危険なものを禁止する」という発想は、想定外の入力に弱いという構造的な限界を抱えています。
拒否リストの逆で、許可する宛先だけを列挙する許可リスト（allow list）方式が対策の中心になります。連携先のドメインやIPアドレスをあらかじめ定義し、それ以外へのアクセスをすべて拒否する考え方です。
OWASPは、SSRF対策の入力検証として、受け取ったデータが妥当なドメイン名であることの確認と、そのドメイン名が信頼できるアプリケーションのものであることの確認という、2つの検証を行うよう示しています（※1）。前方一致や後方一致などのあいまいなチェックでは、サブドメインの偽装などで抜けが生じます。許可した宛先と一致した場合のみ処理するという厳密さが、すり抜けを防ぐ鍵になります。
アプリケーションの実装だけでなく、ネットワーク側の設計も対策の柱です。OWASPは、外部リソースへアクセスする機能を別のネットワークに分離してSSRFの影響範囲を狭めること、そして「deny by default（既定ですべて拒否）」のポリシーを適用し、必要不可欠なイントラネット通信以外をすべて遮断することを推奨しています（※2）。
考え方は、許可リストのネットワーク版です。既定で通信を止めておき、業務上どうしても必要な通信だけを明示的に許可します。こうしておけば、万一アプリケーションがSSRFで突かれても、サーバーが内部の重要システムへ到達する経路そのものが塞がれます。
AWSを利用している場合は、EC2のメタデータ取得をIMDSv2に限定する設定が有効です。IMDSv2はセッション指向の方式で、まず時限付きのセッショントークンを取得し、それをリクエストに付けてはじめてメタデータを利用できます（※3）。単純なリクエストだけでは情報を取得できないため、SSRFを含む複数の脆弱性に対する保護が加わります。
AWSでは、2023年11月以降、マネジメントコンソールのクイックスタートによる起動でIMDSv2のみが使われるようになり、2024年半ば以降に新しくリリースされたインスタンスタイプはIMDSv2のみを使用します（※4）。既存の環境や利用中のサードパーティ製品が対応しているかは個別の確認が必要です。クラウドを使う環境では、この設定を「任意」ではなく「必須」として扱う価値があります。
| 対策 | 主なねらい | 実装の目安 |
|---|---|---|
| 許可リストで宛先を限定 | 意図しない宛先へのアクセスを根本から防ぐ | アプリケーション側の実装。中心的な対策 |
| 拒否リスト・正規表現のみに依存しない | すり抜けを前提に、列挙型の弱点を避ける | 単独では不十分。許可リストに置き換える |
| ネットワーク分離とdeny by default | SSRF発生時の到達範囲を狭める | インフラ設計。影響緩和に有効 |
| クラウドのメタデータをIMDSv2に限定 | 認証情報の窃取リスクを下げる | AWS環境で設定。対応可否の確認が必要 |
なお2024年3月以降は、アカウント単位でIMDSv2を既定にする設定が全リージョンで利用できます。あわせて、IMDSv1の呼び出しが拒否された回数を示すCloudWatchメトリクス「MetadataNoTokenRejected」も提供されており、IMDSv1に依存しているソフトウェアが残っていないかの確認に使えます。
※1 参考：OWASP│Server Side Request Forgery Prevention Cheat Sheet - OWASP Cheat Sheet Series
※2 参考：OWASP│A10 Server Side Request Forgery (SSRF) - OWASP Top 10:2021
※3 参考：Amazon Web Services│IMDSv2 の使用 - Amazon Elastic Compute Cloud
※4 参考：Amazon Web Services│デフォルトでの Amazon EC2 インスタンスメタデータサービス IMDSv2
対策を設計・実装しても、それが実際に機能するかは別の問題です。SSRFは、許可リストの実装ミスや、想定していなかったすり抜け経路によって、意図せず穴が残ることがあります。設計書やコードレビューだけでは、こうした「実際に突けるかどうか」までは判断しきれません。
そこで有効なのが、第三者による脆弱性診断やペネトレーションテストです。ペネトレーションテストは、攻撃者と同じ視点で実際にシステムへ侵入を試み、防御が機能するかを検証する手法です。SSRFのように、リダイレクトやDNSリバインディングといった複雑な条件が絡む脆弱性は、ツールによる自動診断だけでは検出に限界があり、判断を誤ると重大な見落としにつながりかねません。
ユービーセキュアでは、経験を積んだ技術者による手動のWebアプリケーション脆弱性診断とペネトレーションテストを提供しています。複雑な攻撃経路が正しく塞がれているかは、機械的なスキャンよりも専門家の手による検証が適しています。SSRFの対策を実装したあとは、その実装が本当に攻撃を防げるかを、こうした診断で確かめることをおすすめします。
SSRFは、ユーザー入力のURLを検証せずに使うことで、攻撃者が指定した内部リソースへサーバーにリクエストを代理送信させる脆弱性です。ファイアウォールを迂回して内部ネットワークやクラウドの認証情報に届く点が危険で、OWASP Top 10では2021年版のA10を経て、2025年版では最上位カテゴリであるA01（アクセス制御の不備）に統合されています。Capital One事件のように、実際に大規模な情報漏えいを招いた例もあります。
対策の要点は、危険な宛先を弾く拒否リストに頼らず、許可した宛先へ限定する許可リスト方式を中心に据えることです。あわせて、ネットワークを分離して既定で通信を遮断し、AWS環境ではIMDSv2を必須にすることで、多層的に守れます。
最初の一歩として、自社のWebアプリケーションで外部URLを受け取って処理している機能を洗い出してみてください。その機能に許可リストが正しく実装されているかを確認し、実装後は専門家による診断で実際に攻撃を防げるかを検証する。この順序で進めることが、SSRF対策の現実的な進め方です。