「アイコン画像の URL を入力すると、サーバーがその画像を取得して表示する」——どこにでもある機能です。ところがこの一見ありふれた処理が、攻撃者にとってはサーバーを踏み台にして内部ネットワークを覗く入り口になります。入力された URL を、クラウドのメタデータエンドポイント（認証情報が取れる）や、外部に公開していない社内 API に向けられたら、アプリは言われるがままにアクセスし、結果を返してしまう。これが SSRF（Server-Side Request Forgery）です。
地味な脆弱性に見えますが、クラウド上では被害が一気に深刻化します。メタデータ経由でクラウドの一時認証情報を抜かれれば、そこから横展開される。だからこそ対策の標準化が進んでおり、たとえば 2026 年 6 月にリリースされた Spring Boot 4.1 は、HTTP クライアントに SSRF 緩和を組み込みました。フレームワーク側が「危ない宛先への接続を既定で防ぐ」方向に動いているわけです。とはいえ、フレームワーク任せにできない部分は受託側で必ず残ります。
どこで起きるか — 「URLを受け取る機能」すべてが候補
SSRF は特殊な機能ではなく、ユーザー由来の値をもとにサーバーが外部へ通信するあらゆる箇所で起こりえます。受託案件でよく見つかるのは次のような口です。
| 機能 | なぜSSRFになるか |
|---|---|
| 画像・OGP のURL取得 | 入力されたURLをサーバーがそのまま取得する |
| Webhook 登録 | 登録先URLにサーバーが定期的にPOSTする |
| 外部APIのプロキシ | クライアント指定の宛先へサーバーが中継する |
| PDF・サムネイル生成 | レンダラがページ内のURLを解決しに行く |
| インポート機能（URL指定） | 「このURLからデータを取り込む」処理 |
共通点は、宛先を最終的にユーザーが決められることです。攻撃者はそこに http://169.254.169.254/（クラウドメタデータ）や http://localhost:8080/admin、社内 IP を入れてきます。Web アプリの基本的な攻撃面の全体像は Webセキュリティの基本（GH Media） も合わせて確認してください。
「ブロックリスト」ではなく「許可リストと再検証」で塞ぐ
SSRF 対策でやりがちな失敗は、「localhost や 169.254 を含む URL を弾く」というブロックリスト方式です。これは DNS リバインディング（最初は無害な IP を返し、接続時に内部 IP に切り替える）やリダイレクト、IPv6 表記、十進数表記などで簡単にすり抜けられます。受託で「毎回確実に塞ぐ」には、次の型を標準実装にします。
- 宛先を許可リストで絞る：可能なら接続先ドメインをホワイトリスト化する。任意 URL を許す機能でも、スキームを
httpsのみに限定する - 名前解決した実IPを検証する：DNS 解決後の IP がプライベートアドレス・ループバック・リンクローカルでないことを確認する
- 接続時に再検証する：解決時と接続時で IP が変わる DNS リバインディングを防ぐため、実際に接続する IP を固定して検証する
- リダイレクトを追わない／追うなら都度検証：3xx で内部に飛ばされないよう、リダイレクト先も同じ検証にかける
- 送信元を隔離する：外部取得用の処理は、クラウドメタデータや社内 API に到達できないネットワークセグメントから実行する
ポイントは 5 番です。アプリのコードでいくら頑張っても、そもそもメタデータエンドポイントに届かないネットワークに送信処理を置けば、最後の砦になります。ネットワーク分離による多層防御の考え方は マルチテナントの分離と多層防御（GH Media） でも扱いました。
受託で「作るたびに思い出す」をなくす
SSRF が怖いのは、難しいからではなく、機能を作るたびに毎回ゼロから気をつけないといけない点です。画像取得を実装する人、Webhook を足す人、インポートを書く人——担当が違えば対策が漏れます。私たちが受託で入る場合は、これを個人の注意力に任せず、共通の「安全に外部取得するための関数／クライアント」を一つ用意し、URL を受け取る処理は必ずそれを経由させます。検証ロジックを一箇所に集約すれば、レビューもそこを見るだけで済みます。
認証まわりの「毎回ちゃんと実装する」を仕組みにする発想は、トークンの置き場所を題材にした JWTをlocalStorageに置くな問題（GH Media） と同じです。脆弱性は、知識の問題というより「標準化されているか」の問題です。
まず、URLを受け取る機能を棚卸しする
自社のシステムで「ユーザーが指定したURLにサーバーがアクセスする」箇所を洗い出してください。画像取得、Webhook、インポート——思った以上に多いはずです。そのそれぞれが許可リストと実IP検証で守られているか、メタデータに届かない場所から実行されているか。私たちは受託で、この棚卸しと、検証ロジックを一箇所に集約する標準化までをお手伝いしています。
