クローラーのSSRF対策：顧客が登録したURLをそのままリクエストしてはいけない理由

SSRF対策とは何か？

ユーザー提供のアドレスが、内部サービスや許可されていないネットワークへのリクエストを引き起こさないようにするための制御です。 このノートでは、SSRF対策を機能名ではなく、入力・変換・出力それぞれの責任として捉えます。分析結果を信頼するには、どのような資料が入り、何を確認し、どこまで結論を出せるのかが一貫している必要があります。

なぜこの技術が必要なのか？

正常に見えるアドレスでも、リダイレクトや名前解決の後に内部アドレスへ到達することがあります。分析の利便性のためにネットワーク境界を開放すると、テナント全体の信頼が揺らぎます。

設計原則とデータフロー

URLの正規化、許可するプロトコル・ホスト、リダイレクト先、内部アドレスのブロックを、各リクエストの段階で確認します。文字列を一度検査しただけで、ポリシーを満たしたとは言えません。

登録URL → ネットワーク境界の検証 → 許可されたHTTPリクエスト

各段階では、前段階の成功を次の段階の成果として言い換えてはなりません。資料の識別子、期間、検証状態をつなげて記録しておくと、欠落やエラーが発生した箇所を見つけ、再確認する範囲を決められます。

SAGアーキテクチャとの関係

SAGのドメイン登録と収集は、許可されたソースを基準に構成されています。追加の収集アダプターを設計する場合も、同じネットワーク境界を維持することが、この記事で示す拡張ガイドです。

SAGの運用上の価値は、この関係をページや質問、比較結果、改善作業につなげることにあります。顧客は数字だけでなく、補強すべき対象と判断根拠もあわせて検討できます。追加の適用が必要なパターンについては、該当する段落の範囲を基準に読み取ってください。

説明用の例と判断基準

説明用の例として、外部製品のアドレスが内部管理アドレスへリダイレクトする場合、外部アドレスの最初の検証を通過しただけで許可してはなりません。次の遷移先も検証するか、リクエストを中止する必要があります。

上記の例は構造と計算を説明するためのものであり、特定の顧客の実測成果ではありません。実際のレポートでは、選択した期間・対象・観測条件と元の記録を関連付けることで、同じ判断を再確認できるようにする必要があります。

実務での検証チェックリスト

正常な入力だけでなく、空の資料、重複した資料、条件の異なる資料でも同じ意味が保たれるか確認してください。検証項目を作業の完了基準に結び付けることで、機能の説明と実際の運用との差を縮められます。

制限事項と適用時の注意点

ブロックポリシーは、実際のホスティングネットワークとDNS環境に合わせて検証する必要があります。このノートは保護設計の基準を示すものであり、あらゆる環境のセキュリティ認証を意味するものではありません。

研究資料と公式ドキュメント

• OWASP SSRF Prevention Cheat Sheet — ユーザー入力によって生じるサーバーリクエストの信頼境界を検討するための資料です。

外部資料は上記の設計テーマの背景を示すものであり、SAGのすべての実装や顧客成果を認証するものではありません。このノートの適用上の解釈と説明用の例は、SAGの運用構造を基準にまとめています。資料確認日：2026-10-06。

関連記事と機能の確認

• 関連アーキテクチャノート
• SSRF対策に関連するサービスを体験する
• 機能別FAQ
• 導入範囲の相談

この技術をさらに読み進める方法

HTML ZIP・サイトマップ → 正規化 → ページのバージョン → 根拠の記録、という流れをたどります。

• データが根拠になるまでの流れ
• 機能案内FAQ