Garden

最近の記事

クロスオリジンでのFetch - CORS制約の意義

12 min read

Prompt

Fetch APIをクロスオリジンとの通信に使用すると、どうなるか…

うーん、Fetch APIをクロスオリジン通信に使うとき、一体何が起きるか、すごく興味深いトピックだね！🤩

これはWebのセキュリティの**要（かなめ）であり、情報工学を学ぶ君にはぜひ深く理解してほしいCORS (Cross-Origin Resource Sharing)**の話が中心になってくるよ！

🔑 結論: 何も設定していないとブロックされる！

簡単に言えば、セキュリティ上の理由から、デフォルトではブラウザが通信をブロックするんだ。これが「同一オリジンポリシー (Same-Origin Policy, SOP)」だよ。

しかし、Fetch APIを使うクロスオリジン通信は、このSOPの制限をCORSという仕組みを使ってクリアしようとする試みなんだ。

1. デフォルトの挙動（制限）

君がhttps://example.comで動作するWebページから、https://api.external.com/dataへfetch()でリクエストを送った場合を考えてみよう。

項目動作理由
リクエストの送信リクエスト自体は送信されることが多い。ブラウザは悪意のあるリクエストかどうかを判断するために、とりあえず送信はする。
レスポンスの受信サーバーからのレスポンスは無事に届く。HTTPレベルでは通信は成功している。
JavaScriptからのアクセスJavaScriptのコード（fetch().then(...)）からはレスポンスを読み取れない。ブラウザがCORSのチェックに失敗したと判断し、レスポンスを隔離（隔離）してJSに渡さない。コンソールにエラーが表示される。

2. CORSの魔法: サーバー側の設定が必須！

この問題を解決して、ブラウザに「このクロスオリジン通信は安全だよ」と許可してもらうには、通信先のサーバーに特別な設定をしてもらう必要があるんだ。

サーバーはHTTPレスポンスヘッダーに次の情報を追加する必要があるよ。

ヘッダー名値の例意味
Access-Control-Allow-Originhttps://example.com または *どのオリジンからのリクエストを許可するか。*は全てを許可する（テスト環境以外では非推奨）。
Access-Control-Allow-MethodsGET, POST, OPTIONS許可するHTTPメソッド。
Access-Control-Allow-HeadersContent-Type, Authorization許可するカスタムヘッダー。

これが設定されていれば、ブラウザはレスポンスヘッダーを見て「OK、この通信はサーバー側が許可しているから安全だね！」と判断し、Fetch APIのPromiseが解決され、JSコードからレスポンスデータにアクセスできるようになるんだ！

3. 特殊なケース: プリフライト・リクエスト (Preflight Request)

Fetch APIで、POSTやPUTを使ったり、カスタムヘッダーを付けたりする**「複雑なリクエスト」を送るときは、本命のリクエストの前に、ブラウザが自動的にOPTIONSメソッドを使ったプリフライト・リクエスト**を送信するんだ！

このプリフライト・リクエストは、

  1. 「これからこんなリクエストを送りたいんだけど、許可してくれる？」とサーバーに事前に問い合わせる。

  2. サーバーがAccess-Control-Allow-*ヘッダーで許可を返せば、

  3. 初めて本命のPOSTリクエストなどが送信される。

このプリフライト処理が成功しないと、そもそも本命のデータ送信すら行われないから、サーバー側の設定は本当に重要なんだよ！💡

君が将来、JavaやPHPでバックエンドAPIを構築するときは、このCORSの設定（ミドルウェアやフィルター）を必ず意識することになるから、今から仕組みを理解しておくと最強だね！プログラミングの世界って、こういうセキュリティの裏側を知るとさらに楽しいよね！🥳

Prompt

もう一つ疑問。この制約はクライアントとサーバー、どちらの安全を守るため？

それはまた核心を突く素晴らしい質問だね！😎

この同一オリジンポリシー (SOP)とそれを緩和するCORSの制約は、基本的にはクライアント側（ユーザーのブラウザ）の安全を守るために存在するんだ。

🛡️ クライアント（ブラウザ）の安全

Webのセキュリティモデルは、「悪意のあるウェブサイトが、あなたのブラウザに保存されている重要なデータ（銀行のログインセッションやCookieなど）を盗み見たり、勝手に操作したりするのを防ぐ」ことに重点を置いているんだ。

攻撃シナリオの防止

もしSOPがなかったら、こんな恐ろしいことが起こる可能性があるよ。

  1. **悪意のあるサイト（例: http://bad-hacker.com）**をユーザーがたまたま開く。

  2. このサイトのJavaScriptが、裏で**ユーザーがログインしている銀行のサイト（例: https://bank.com）**に対してfetch()リクエストを送る。

    • このリクエストには、ユーザーが銀行にログインしたときに保存された**認証情報（Cookieなど）**が自動的に付与されてしまう。

  3. 銀行のサーバーは、認証情報があるから正常に口座情報をレスポンスとして返す。

  4. SOPがなければ、bad-hacker.comのJavaScriptは、このレスポンスボディ（口座情報）を自由に読み取って、自分のサーバーに送信できてしまう。

SOPとCORSの役割

  • SOP (同一オリジンポリシー): これが働いているから、ステップ4で**「レスポンスは受け取れたけど、JSからは読み取れない（隔離される）」**という事態になる。これでデータの盗難を防げるんだ。

  • CORS (クロスオリジンリソース共有): これは、サーバー側（この例では銀行）が「うちのデータは、bad-hacker.com以外の、信頼できるオリジン（例: https://partner.com）になら読み取りを許可しますよ」と明示的に宣言するためのメカニズムなんだ。

サーバー側も守られるか？

サーバー側の安全を守るのは、主にサーバー自身の認証・認可の仕組みや、CSRF（クロスサイトリクエストフォージェリ）対策なんだ。

SOPやCORSは、サーバーを完全に守るわけではないよ。

  1. SOPがあっても、リクエスト自体はサーバーに届いちゃう。

  2. サーバー側では、そのリクエストが正当な認証情報を持っているか、意図した操作かをチェックする必要がある。

まとめ

この制約の主な目的は、クライアントのブラウザセッションと機密データが悪意のある第三者のサイトのJavaScriptに盗み見られたり、勝手に利用されたりするのを防ぐことにあるんだ。つまり、ユーザーの安全が最優先ってわけ！😊

Prompt

この制約は、XSS攻撃によって”本来無害な”サイトに埋め込まれたfetchメソッドには効果がない？

なるほど！XSS (Cross-Site Scripting) 攻撃とCORS/SOPの関係性についてだね。これはWebセキュリティの論理的な境界線を理解する上で、めちゃくちゃ重要なポイントだよ！🔥

結論から言うと、君の指摘の通り、**「XSS攻撃によって埋め込まれたfetchメソッドには、同一オリジンポリシー（SOP）やCORSの制約は基本的に効果がない」**と言えるんだ。

🚨 理由：オリジンの概念

SOPやCORSの制約が適用されるのは、「オリジン（Origin）が異なる」通信に対してだよね。

  1. XSS攻撃とは？

    • 攻撃者が、セキュリティホールのある信頼されたサイトA（例：銀行のサイトhttps://bank.com）のページに、悪意のあるJavaScriptコードを埋め込む行為。

    • この悪意あるコードは、ユーザーがそのページを開いたときに実行される。

  2. 埋め込まれたfetch()の実行オリジン

    • XSSによって埋め込まれたfetch()は、信頼されたサイトA（https://bank.com）のスクリプトとして実行される。

    • つまり、**実行オリジンはhttps://bank.com**になるんだ。

  3. SOP/CORSの判断

    • Fetch APIがリクエストを送るとき、ブラウザは送信元オリジンと宛先オリジンを比較する。

    • 宛先がhttps://bank.com自身であれば、それは同一オリジン通信として扱われる。SOPもCORSも制約を加えないんだ。

    • 宛先が他のオリジンであっても、攻撃者はhttps://bank.comのスクリプトとして実行しているため、ブラウザが許可する全ての操作（Cookieの読み取り、フォーム送信など）を、そのサイトの権限で行えてしまう。

🔍 XSSとSOP/CORSの役割分担

これは、それぞれのセキュリティ対策の守備範囲が違うことを示しているよ。

セキュリティ対策守備範囲破られた場合の影響
SOP/CORS異なるオリジン間でのリソース（データ）の読み取りを防ぐ。悪意のあるサイトBが、サイトAのデータを盗むのを防ぐ。
XSS対策信頼されたサイト内に、悪意のあるスクリプトが埋め込まれるのを防ぐ。サイトの権限で何でもできてしまう（Cookie盗難、勝手な操作、他のサイトへの攻撃）。

つまり、SOP/CORSは、外部（違うオリジン）からの攻撃を防ぐ防御壁。

対してXSS対策は、内部（同じオリジン）に侵入した攻撃者を無効化する門番のようなものだね！

セキュリティ対策は多層防御が鉄則！XSSを許すと、SOP/CORSという大きな防御壁の内側から、サイトの全権限を使って好き放題されてしまうから、XSS対策は非常に重要なんだ！👍

グラフビュー

最近の記事

グラフビュー