CORSの仕組み――なぜブラウザは「よそのサーバー」を警戒するのか

CORSは「Cross-Origin Resource Sharing」の略で、日本語だと「オリジン間リソース共有」だね。ブラウザには「同一オリジンポリシー」っていうセキュリティルールがあって、あるWebページから別のオリジンのサーバーへリクエストを送るのを原則ブロックするんだ。CORSはそのブロックを安全に解除するための仕組みだよ。

オリジンは「スキーム＋ホスト＋ポート」の3つの組み合わせだよ。例えば https://example.com:443 と http://example.com:80 はスキームが違うから別オリジン。https://example.com と https://api.example.com もホストが違うから別オリジン。3つ全部一致して初めて「同一オリジン」になるんだ。

もし制限がなかったら、悪意のあるサイトを開いただけで、そのページのJavaScriptがあなたのログイン済みの銀行サイトやSNSに勝手にリクエストを送れちゃうんだ。Cookieも一緒に送られるから、残高を見たり送金したりできてしまう。同一オリジンポリシーは、そういう攻撃からユーザーを守るためのブラウザの防壁だよ。

サーバー側がレスポンスヘッダーで「このオリジンからのアクセスは許可するよ」と明示するんだ。代表的なのが Access-Control-Allow-Origin ヘッダーで、例えば Access-Control-Allow-Origin: https://myapp.com と返せば、myapp.comからのリクエストだけ許可される。ワイルドカード * を指定すれば全オリジン許可だけど、セキュリティ的には必要最小限にするのが鉄則だよ。

いい質問だね。ブラウザは「シンプルリクエスト」と「それ以外」を区別するんだ。GETやPOSTで、Content-Typeが application/x-www-form-urlencoded、multipart/form-data、text/plain のいずれかなら、シンプルリクエストとしてそのまま送信される。でもPUTやDELETE、あるいはContent-Typeが application/json のPOSTなどは、本番リクエストの前にOPTIONSメソッドで「プリフライトリクエスト」が飛ぶんだ。

ブラウザがまずOPTIONSリクエストを送って、Access-Control-Request-Method（使いたいHTTPメソッド）と Access-Control-Request-Headers（使いたいヘッダー）を伝える。サーバーはそれに対して Access-Control-Allow-Methods、Access-Control-Allow-Headers、Access-Control-Max-Age（プリフライト結果のキャッシュ秒数）をレスポンスで返す。ブラウザはこの応答を見て「OK、許可されてるな」と判断してから本番リクエストを送るんだよ。

クレデンシャル（CookieやHTTP認証情報）を送るには、クライアント側で fetch の credentials: 'include' を指定して、サーバー側で Access-Control-Allow-Credentials: true を返す必要があるんだ。ここで重要なのが、Allow-Originにワイルドカード * は使えないということ。必ず具体的なオリジンを指定しないといけない。これはブラウザが「全世界にCookieを送ってOK」という状態を防ぐためだよ。

まずブラウザのDevToolsのNetworkタブを開いて、OPTIONSリクエストが飛んでいるか、そのレスポンスヘッダーに正しいAllow系ヘッダーがあるかを確認しよう。よくあるミスは、サーバーがOPTIONSに200を返していない、Allow-Originが設定されていない、Allow-Headersに Authorization が入っていない、などだね。CORSエラーのメッセージはブラウザによって微妙に違うけど、Chromeなら原因がかなり具体的に書かれるから読んでみるといいよ。

起きないよ。CORSはあくまでブラウザだけのセキュリティ機構なんだ。curlやNode.jsのfetch、PythonのrequestsなどサーバーサイドからのHTTPリクエストにはCORS制限は一切かからない。だから「ローカルのcurlでは動くのにブラウザからだと動かない」というのは典型的なCORS問題だね。プロキシサーバーを挟んで回避するパターンもこの性質を利用しているんだよ。

あるよ。特に危険なのが、リクエストのOriginヘッダーをそのまま Access-Control-Allow-Origin に反射する実装だね。これだと任意のサイトからのアクセスを許可しているのと同じで、Credentials: trueと組み合わせると、攻撃者のサイトからユーザーのCookie付きでAPIを叩き放題になる。あと、CORSとCSRF対策を混同する人も多いけど、CORSは「レスポンスの読み取り」を制御するもので、リクエスト送信自体はブロックしない。CSRF対策にはCSRFトークンなど別の仕組みが必要だよ。

そうだね。CORSは「ブラウザがユーザーを守るための仕組み」で、サーバーが「どこからのアクセスを信頼するか」をヘッダーで宣言する仕組みだと覚えておこう。DevToolsのNetworkタブでOPTIONSリクエストとレスポンスヘッダーを確認する習慣をつければ、CORSエラーに悩まされることは激減するよ。