# SSRFとは？仕組みと被害、許可リストを軸にした対策を解説

SSRF（サーバーサイドリクエストフォージェリ）の仕組みと起こりうる被害、許可リスト・リダイレクト無効化・通信経路の分離・IMDSv2による対策を、OWASPとAWSの資料をもとにWeb開発者向けに解説します。

SSRF（サーバーサイドリクエストフォージェリ）は、Webアプリケーションのサーバーを悪用して、内部ネットワークや外部、サーバー自身へ意図しないリクエストを送らせる攻撃です。外部から直接は届かない内部のサービスに、サーバーを経由して届いてしまう点が問題です。対策の基本は、接続先を許可リストで絞り、通信経路そのものも制限することです。

<Points>

- 利用者が指定したURLをサーバーが取りに行く機能（画像取得やWebhookなど）で起こりやすい
- 対策の軸は許可リスト。拒否リストは回避されやすく、OWASPは最後の手段としている
- アプリ側の検証に加えて、ネットワークの分離とクラウドのメタデータ保護を重ねる

</Points>

## SSRFとは

通常、社内のAPIやデータベースの管理画面はインターネットから直接アクセスできません。しかしWebサーバーはそれらと同じネットワークにあることが多く、サーバーが出すリクエストは届きます。SSRFはこの関係を利用する攻撃です。

OWASPのチートシートは、起点の多くはURLの扱いの不備だとして、次のような機能を例に挙げています。

<Figure title="SSRFに注意したい機能の例" source="OWASP Server-Side Request Forgery Prevention Cheat Sheet">

| 機能 | サーバーがすること |
| --- | --- |
| アバター画像の取得 | 利用者が指定したURLから画像を取りに行く |
| Webhook | 利用者が登録したURLへ通知を送る |
| 内部サービスの呼び出し | 利用者のデータを含めて別のサービスへリクエストを送る |

</Figure>

対象はHTTPに限りません。OWASPは `file://` など他のスキームも使われうること、XXE（XML外部実体参照）がSSRFにつながることも挙げています。

OWASP Top 10では、2021年版で独立したA10だったSSRFが、2025年版ではA01「Broken Access Control」に統合されました（CWE-918）。全体の変更点は[OWASP Top 10の解説](/owasp-top-10/)にまとめています。

## 起こりうる被害

OWASPのコミュニティページは、影響の例として次を挙げています。クラウド環境では、メタデータサービスから認証情報やアクセストークンを盗む目的でよく使われるとチートシートも説明しています。

<Figure title="SSRFで起こりうる被害" source="OWASP「Server Side Request Forgery」">

| 狙われるもの | 起こりうること |
| --- | --- |
| クラウドの設定情報 | 重要な設定や、場合によっては認証用の鍵が読まれる |
| 内部のデータベース | 内部利用が前提で認証のない管理用インターフェースからデータを取られる |
| 内部のAPI | 公開を想定していないWebサービスを呼び出される |
| サーバー上のファイル | サーバー内のファイルを読まれる |

</Figure>

<Flow
  title="SSRFで内部に届いてしまう流れ"
  steps={[
    { label: "URLを受け取る機能に値を送る", note: "画像取得やWebhookの登録など" },
    { label: "サーバーが検証せずリクエストを送る", note: "接続元はサーバー自身になる" },
    { label: "内部のサービスに届く", note: "外部からは届かない宛先" },
    { label: "応答や処理の結果を悪用される", note: "情報の取得や内部の操作" },
  ]}
/>

## 接続先が決まっている場合の対策

OWASPは、接続先が事前に分かっている場合と、任意の外部へ接続する必要がある場合に分けて対策を示しています。まず、機能を見直して前者にできないかを確認します。

<Compare>
<Column title="接続先が決まっている" tone="accent">

- 許可リストで絞る
- URL全体を受け取らない
- スキーム・ポート・パスはサーバー側で固定する

</Column>
<Column title="任意の外部に接続する">

- 許可リストが現実的でない
- 内部向けの宛先を拒否する
- 接続先側でトークンを確かめる

</Column>
</Compare>

接続先が決まっているなら、URL全体を入力として受け取らず、サーバー側でURLを組み立てます。次の例では、利用者が指定できるのは画像のIDだけです。

```js
const imageIdPattern = /^[a-z0-9-]{1,64}$/;

const fetchImage = async ({ imageId }) => {
  if (!imageIdPattern.test(imageId)) {
    throw new Error("画像のIDが正しくありません");
  }

  return fetch(`https://images.example.com/${imageId}`, {
    redirect: "error",
  });
};
```

`redirect: "error"` は、リダイレクトの応答が返ったときにリクエストを失敗させるFetch APIの指定です。既定値は `follow` で、リダイレクト先まで自動で取りに行きます。OWASPは、リダイレクトが入力値の検証をすり抜ける手段になるとして、HTTPクライアントのリダイレクト追従を無効にするよう勧めています。

## 任意の外部に接続する場合の対策

Webhookのように宛先を事前に決められない機能では、次を組み合わせます。

<Steps>
<Step title="解決後のIPアドレスを確かめる">

ドメイン名だけでなく、名前解決した結果のIPアドレスがプライベート・ローカル・リンクローカルの範囲でないかを確かめ、確かめたアドレスにだけ接続します。名前解決の確認と接続を別々に行うと、その間に結果を変えられるおそれ（DNSリバインディング）があります。

</Step>
<Step title="プロトコルと送る内容を限定する">

プロトコルは許可リスト（HTTPまたはHTTPS）で確かめます。OWASPは、接続先へ渡すパラメータ名やトークンの形式も送信前に検証する方法を示しています。

</Step>
<Step title="接続先に正当性を確かめさせる">

接続先のアプリケーションが発行したランダムなトークンを、POSTで受け取って確かめる方法です。

</Step>
<Step title="リダイレクトを追わない">

検証を通ったURLから別の宛先へ転送されないように、追従を無効にします。

</Step>
</Steps>

<Note tone="caution">

拒否リストだけに頼らないでください。OWASPは拒否リストを「回避されやすい」として、許可リストを優先するよう明記しています。やむを得ず使う場合も、クラウドのメタデータのアドレス、localhost、RFC1918のプライベート範囲、IPv6のユニークローカルとリンクローカル、マルチキャストを最低限拒否するよう示しています。

</Note>

## ネットワークとクラウド側の対策

アプリケーションの検証は、1か所漏れると破られます。OWASPは通信経路の制限も重ねるよう勧めています。

<Figure title="アプリの外で重ねる対策" source="OWASP Server-Side Request Forgery Prevention Cheat Sheet、AWS「Use the Instance Metadata Service」">

| 対策 | 内容 |
| --- | --- |
| 外向き通信の制限 | ファイアウォールで、必要な通信先だけを許可する |
| ネットワークの分離 | 不正な呼び出しをネットワークの段階で止める（OWASPは強く推奨） |
| IMDSv2の必須化 | AWSのメタデータサービスでIMDSv1を止め、IMDSv2だけを受け付ける |

</Figure>

AWSのIMDSv2は、PUTリクエストでセッション用のトークンを作り、以後のリクエストにそのトークンを付けるセッション方式です。AWSの設定により、IMDSv2の呼び出しだけを受け付けるようにできます。OWASPは、これを一部のSSRFを和らげる多層防御の一つとしており、完全な解決策ではないとしています。

## よくある質問

### Q. SSRFとCSRFは何が違いますか？

リクエストを送らされる主体が違います。CSRFでは利用者のブラウザが標的サイトへリクエストを送らされ、SSRFではサーバーが内部や外部へリクエストを送らされます。CSRFの仕組みは[CSRFの解説](/csrf/)にまとめています。

### Q. 入力されたURLのホスト名を確認するだけで十分ですか？

十分ではありません。OWASPは、パーサーによって別のホストに読めるURLの拒否、解決後のIPアドレスの確認、リダイレクトの無効化を求めています。可能であれば、URL全体を受け取らない設計に変えてください。

### Q. IMDSv2にしておけばSSRF対策は不要ですか？

不要にはなりません。IMDSv2が守るのはメタデータサービスへの経路で、内部のAPIやデータベースへの到達は別の問題です。OWASPも多層防御の一つと位置づけています。

出典: [OWASP Server-Side Request Forgery Prevention Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Server_Side_Request_Forgery_Prevention_Cheat_Sheet.html)、[OWASP「Server Side Request Forgery」](https://community.owasp.org/attacks/Server_Side_Request_Forgery)、[OWASP Top 10:2025 A01 Broken Access Control](https://top10.owasp.org/2025/A01_2025-Broken_Access_Control/)、[OWASP Top 10:2025 Introduction](https://top10.owasp.org/2025/0x00_2025-Introduction/)、[AWS「Use the Instance Metadata Service to access instance metadata」](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-instance-metadata-service.html)、[MDN「RequestInit」](https://developer.mozilla.org/en-US/docs/Web/API/RequestInit)