AI Overview診断ツールでは、記事本文を直接入力して診断する方法に加えて、URLを入力して対象ページを取得し、内容を診断する機能を用意できます。
たとえば、ユーザーが記事URLを入力すると、アプリ側がそのページを取得し、本文を抽出して診断します。
この機能は便利ですが、注意すべきセキュリティリスクがあります。
それが SSRF です。
SSRFとは？
SSRFとは、Server-Side Request Forgery （サーバーサイド・リクエスト・フォージェリ）の略です。
簡単にいうと、ユーザーが入力したURLを使って、サーバーに本来アクセスしてはいけない場所へアクセスさせる攻撃です。
通常、URL診断機能では次のような流れになります。
ユーザーがURLを入力
↓
サーバーがそのURLへアクセス
↓
HTMLを取得
↓
本文を抽出
↓
診断する本来は、公開されているWebページを取得するための処理です。
しかし、悪意あるユーザーが、外部公開ページではなく、サーバー内部やローカルネットワーク向けのURLを入力する可能性があります。
なぜSSRFが危険なのか？
攻撃者のPCからはアクセスできない場所でも、アプリのサーバーからはアクセスできる場合があります。
たとえば、サーバー内部の管理画面、クラウド環境のメタデータ、社内ネットワーク上のサービスなどです。
攻撃者は、自分で直接アクセスするのではなく、あなたのアプリのサーバーに代理でアクセスさせようとします。
つまり、アプリのサーバーが踏み台にされる危険があります。
AI Overview診断ツールで特に注意する機能
SSRF対策が必要になるのは、主にURL診断機能です。
本文を直接入力する診断では、外部URLへアクセスしません。
一方、URL診断では、ユーザーが入力したURLへサーバー側からアクセスします。
そのため、次のような構成では注意が必要です。
AI Overview診断ツール
↓
Next.js API Route
↓
入力URLのページを取得
↓
本文を抽出
↓
ローカルLLMまたはルールベースで診断
↓
Supabaseに診断履歴を保存特にSaaS化して、誰でもURLを入力できる状態にする場合は、SSRF対策は必須です。
拒否すべきURLの例
URL診断機能では、次のようなアクセス先を拒否する必要があります。
| 種類 | 危険性 |
|---|---|
| localhost | サーバー自身の内部機能にアクセスされる可能性 |
| 127.0.0.1 | ローカル内部サービスへアクセスされる可能性 |
| 0.0.0.0 | 特殊なアドレスとして悪用される可能性 |
| 10.x.x.x | プライベートネットワークへアクセスされる可能性 |
| 172.16.x.x〜172.31.x.x | プライベートネットワークへアクセスされる可能性 |
| 192.168.x.x | 社内・家庭内ネットワークへアクセスされる可能性 |
| 169.254.x.x | クラウドメタデータ等へアクセスされる可能性 |
| IPv6のローカル系アドレス | 内部ネットワークへアクセスされる可能性 |
| file:// などHTTP以外 | ローカルファイル等への不正アクセスにつながる可能性 |
特に 169.254.169.254 のようなクラウドメタデータ系のアドレスは、クラウド環境で重要な情報に関係することがあるため、必ず拒否対象として考えます。
SSRF対策の基本方針
SSRF対策のポイント
URL診断機能では、ユーザーが入力したURLをサーバー側でそのまま取得してはいけません。
http/httpsのみを許可し、localhost、プライベートIP、リンクローカルIP、クラウドメタデータ系アドレスを拒否します。
さらに、リダイレクト先の確認、タイムアウト、サイズ制限、HTML以外の拒否も行うことで、安全性を高められます。
SSRF対策では、次の考え方が重要です。
ユーザー入力を信用しない
↓
アクセスしてよいURLだけ許可する
↓
内部向けURLは拒否する
↓
リダイレクト先も確認する
↓
取得時間と取得サイズを制限する単に「URLの形式になっているか」を確認するだけでは不十分です。
一見すると普通のドメインに見えても、内部IPへ解決される場合や、リダイレクトで危険なURLへ飛ばされる場合があるためです。
実装時に入れたいチェック項目
AI Overview診断ツールでURL診断機能を安全にするには、次のチェックを入れるとよいです。
| チェック項目 | 内容 |
|---|---|
| URL形式チェック | 正しいURL形式か確認する |
| スキーム制限 | http と https のみ許可する |
| ホスト名チェック | localhost や内部ドメインを拒否する |
| IPアドレスチェック | プライベートIP、ループバックIP、リンクローカルIPを拒否する |
| DNS解決後のチェック | ドメイン名が内部IPに解決されないか確認する |
| リダイレクト先チェック | リダイレクト後のURLも再確認する |
| タイムアウト設定 | 応答しないURLで処理が止まらないようにする |
| サイズ制限 | 巨大なHTMLやファイルを取得しないようにする |
| Content-Type確認 | HTML以外を診断対象にしない |
| レート制限 | 短時間に大量のURL診断を実行されないようにする |
URL取得処理は共通化する
実装上は、URLを取得する処理をアプリ内のあちこちに直接書かないことが重要です。
たとえば、URL診断機能、再診断機能、履歴からの再取得機能などで、それぞれ別々にURL取得処理を書いてしまうと、対策漏れが起きやすくなります。
そのため、次のような専用処理にまとめるのが安全です。
安全なURL取得処理
├─ URL形式チェック
├─ http / https のみ許可
├─ 内部IP拒否
├─ DNS解決後の確認
├─ リダイレクト先確認
├─ タイムアウト
├─ サイズ制限
└─ HTMLのみ許可この共通処理を通ったURLだけを診断対象にします。
リダイレクトにも注意する
SSRF対策で見落としやすいのが、リダイレクトです。
最初に入力されたURLが安全に見えても、そのページが別のURLへリダイレクトする場合があります。
一見安全なURL
↓
リダイレクト
↓
内部IPやlocalhostへ移動このような動きを許してしまうと、最初のURLだけ検査しても意味がありません。
URL診断機能では、リダイレクト先のURLも毎回チェックする必要があります。
また、無限リダイレクトを防ぐため、リダイレクト回数にも上限を設けます。
タイムアウトとサイズ制限も重要
SSRF対策というと、内部URLの拒否だけに目が向きがちです。
しかし、URL取得機能では、サーバー負荷対策も重要です。
たとえば、応答が非常に遅いURLや、巨大なファイルを返すURLを指定されると、サーバーの処理が長時間止まったり、メモリを大量に消費したりする可能性があります。
そのため、次の制限を入れておくと安全です。
取得時間の上限
取得サイズの上限
HTML以外の拒否
同一ユーザーの連続実行制限これらは、SSRF対策だけでなく、SaaSとしての安定運用にも役立ちます。
SaaS化する場合は認証と回数制限も必要
AI Overview診断ツールをSaaS化する場合、URL診断機能はログインユーザーに限定したほうが安全です。
未ログインでも自由にURL診断できる状態にすると、攻撃や大量アクセスの踏み台にされやすくなります。
おすすめは次の形です。
ログイン済みユーザーのみURL診断可能
↓
ユーザーごとに診断回数を制限
↓
拒否されたURLやエラーを記録
↓
不審な利用を管理画面で確認これにより、攻撃の早期発見や利用制限がしやすくなります。
Supabase保存時の注意点
診断履歴をSupabaseに保存する場合、拒否したURLや取得失敗したURLをどこまで保存するかも考える必要があります。
保存すると便利な情報は次のようなものです。
ユーザーID
入力されたURL
診断成功・失敗の状態
拒否理由
実行日時ただし、取得したHTML全文やエラー詳細をそのまま保存するのは避けたほうがよい場合があります。
ログに機密情報や不要な本文が残る可能性があるためです。
SaaSとして運用するなら、保存するログは必要最小限にします。
まとめ
SSRFは、ユーザーが入力したURLを利用して、サーバーに本来アクセスしてはいけない場所へアクセスさせる攻撃です。
AI Overview診断ツールのURL診断機能では、サーバー側が外部ページを取得するため、SSRF対策が欠かせません。
URL診断機能は便利ですが、ユーザー入力URLをそのまま取得する設計は危険です。
特にSaaS化する場合は、次の対策を入れることが重要になります。
http / https のみ許可
localhostを拒否
プライベートIPを拒否
リンクローカルIPを拒否
クラウドメタデータ系アドレスを拒否
DNS解決後のIPも確認
リダイレクト先も確認
タイムアウトを設定
サイズ制限を設定
HTML以外を拒否
ログインユーザーに限定
診断回数を制限