LASSIC Media らしくメディア

Webシステムやアプリの開発で、「ブラウザのコンソールに『CORS policy によってブロックされました』というエラーが出ている」「ベンダーから『CORSの設定を直します』と説明を受けたが、それが何を指すのか掴みづらい」——IT事業部で開発の進捗や不具合の報告を受ける立場にいると、こうした場面に出くわすことがあるのではないでしょうか。CORS（コルス）は、Webブラウザが別のサイト（オリジン）へアクセスする際に働く仕組みで、フロントエンドと別ドメインのAPIを連携させる構成では、ほぼ例外なく関わってきます。画面には現れないため発注者やPMにとってはイメージしづらい領域ですが、その考え方を大まかに理解しておくと、なぜエラーが起きるのか、どちらの責任範囲で直すのか、といった判断がしやすくなるはずです。本記事では、特定の製品の設定手順ではなく、CORSとはそもそも何を指すのか、なぜ必要で、どんな仕組みで動き、開発・運用で何に気をつけるべきかを、発注・運用の視点から順に整理します。用語をすべて覚える必要はありませんが、「ブラウザが利用者を守るための仕組み」という勘所をつかんでおくと、ベンダーとの会話の解像度が変わってくるでしょう。

CORSとは何か

CORS（Cross-Origin Resource Sharing、オリジン間リソース共有）とは、あるWebサイトから別のオリジンにあるデータへ、ブラウザ経由でアクセスしてよいかどうかを制御する仕組みです。ここでいう「オリジン」とは、URLのうち「スキーム（httpsなど）＋ホスト名＋ポート番号」の組み合わせを指します。この3つがすべて一致していれば同じオリジン、一つでも違えば別のオリジン（クロスオリジン）という扱いになります。たとえば「https://app.example.com」から「https://api.other.com」のAPIを呼び出す場合、ホスト名が違うため、両者は別オリジンの関係です。

同一オリジンかどうかは、パスやクエリではなく、あくまでスキーム・ホスト名・ポートの3点で決まります。基準URLを「https://app.example.com」としたとき、どれが同一で、どれが別オリジンになるかを整理すると次のようになります。

このように、見た目が近いURLでも、3点のどれか一つが違えば別オリジンとして扱われます。開発と本番でドメインが分かれていたり、フロントとAPIでサブドメインを分けていたりすると、自然とクロスオリジンの構成になる、という点を押さえておくとよいでしょう。

ブラウザには、原則として「自分が表示しているサイトと同じオリジンのデータにしかアクセスさせない」という守りの仕組みが組み込まれています。これを同一オリジンポリシーと呼びます。CORSは、この原則にあえて例外を設け、サーバ側が「このオリジンからのアクセスは受け入れてよい」と明示的に許可を出すことで、別オリジンへのアクセスを可能にする取り決めです。言い換えれば、CORSは制限そのものではなく、制限をゆるめて別オリジン間の連携を成り立たせるための仕組みだといえます。

ここで最初に押さえておきたい大切な点があります。CORSは「サーバを守るセキュリティ機能」ではなく、「ブラウザが利用者（エンドユーザー）を守るための仕組み」だという点です。判断してアクセスを止めているのはサーバではなく、利用者の手元にあるブラウザです。そのため、サーバ同士がバックエンドで直接通信する場面には、CORSは関係しません。この主語の違いを意識しておくと、後で触れるエラーの理解がぐっと楽になるでしょう。

なぜオリジン間の制限があるのか

そもそも、なぜブラウザはオリジンをまたぐアクセスを原則として制限しているのでしょうか。背景には、利用者のなりすまし被害を防ぐという狙いがあります。

たとえば、あなたがオンラインバンキングにログインした状態のまま、別のタブでたまたま開いた不審なサイトがあったとしましょう。もし何の制限もなければ、その不審なサイトに仕込まれたプログラムが、あなたのブラウザを使って裏側でバンキングのAPIを勝手に呼び出し、残高や個人情報を読み取ってしまうおそれがあります。ログイン情報はブラウザが保持しているため、利用者本人が操作したかのように振る舞えてしまうのです。同一オリジンポリシーは、こうした「別サイトからの勝手なデータの読み取り」をブラウザの段階で遮り、利用者を守っています。

とはいえ、現代のWebでは、フロントエンドの画面と、データを返すAPIサーバを別のドメインに分ける構成がごく一般的です。この場合、正規のアプリであってもオリジンをまたいだ通信が必要になります。そこで、やみくもにすべてを禁じるのではなく、サーバ側が「このオリジンになら読ませてよい」と選んで許可できるようにしたのがCORSです。つまりCORSは、利用者を守る原則を保ちつつ、正規の連携だけを通すための、いわば例外許可の仕組みだと捉えると分かりやすいでしょう。

CORSの仕組み

では、CORSは具体的にどのように動くのでしょうか。中心にあるのは、サーバがレスポンスに付ける「許可を示す情報（HTTPヘッダ）」です。

ブラウザが別オリジンへリクエストを送ると、そのリクエストには「どのオリジンから来たか」を示す情報（Originヘッダ）が自動的に添えられます。サーバはそれを見て、受け入れてよい相手であれば、レスポンスに「Access-Control-Allow-Origin」という許可ヘッダを付けて返すのです。ブラウザは、この許可ヘッダに自分のオリジンが含まれているかを確認し、含まれていれば応答をアプリに渡し、含まれていなければ応答を破棄してエラーとして扱います。次の図は、この流れを単純化して示したものです。

もう一つ、CORSには「プリフライトリクエスト」という段取りがあります。データの書き換えを伴う操作など、影響の大きいリクエストを送る前に、ブラウザはまず「OPTIONS」という確認用のリクエストをサーバへ送り、「この方式・この項目でアクセスしてよいか」を事前に問い合わせる仕組みです。サーバが許可を返して初めて、本来のリクエストが送られます。いわば、本番の前に一度ノックして許可を得るような段取りです。これがあるため、CORS対応では、本来のデータのやり取りだけでなく、この事前確認への応答も正しく設定しておく必要があります。

ここで、少し細かい点にも触れておきたいところです。CORSがブロックするのは、多くの場合「レスポンスをアプリに読ませること」であって、リクエストがサーバに届くこと自体をつねに止めるわけではありません。単純なリクエストでは、サーバまで通信が届いて処理された後、返ってきた応答をブラウザが読ませないという形で制御されることもあります。つまり「APIは呼ばれているのに画面にはエラーが出る」という、一見ちぐはぐな状況が起こり得るのです。これも、判断しているのがサーバではなくブラウザだからこその挙動だといえるでしょう。

よくあるCORSエラーと勘違い

CORSは、開発現場でエラーに遭遇しやすい領域です。代表的なエラーの見え方と、その背景にある勘違いを整理しておきましょう。

これらに共通するのは、「CORSエラーはブラウザが出しているもので、多くはサーバ側の許可設定で解決する」という点です。切り分けの際に、どちらの責任範囲の話なのかを取り違えると、原因の特定に時間がかかってしまいます。エラーメッセージに戸惑ったときは、まず「ブラウザが許可ヘッダを見て止めているのだ」と思い出すと、話が整理しやすくなるでしょう。

開発・運用で意識したい観点

CORSは仕組み自体は素直ですが、実運用でつまずかないために、発注や設計の会話で押さえておきたい観点がいくつかあります。

第一に、許可するオリジンの管理です。開発・検証・本番でドメインが分かれる場合、それぞれのオリジンを許可先として設定しておく必要があります。環境が増えるたびに設定漏れが起きやすいため、どこを許可しているかを一覧で管理できるようにしておくと運用の見通しが立ちます。第二に、許可範囲を絞る考え方です。手間を惜しんですべてのオリジンを許可すると、意図しない相手にデータを読ませてしまうリスクが高まります。原則は「必要なオリジンだけを許可する」で、対象を最小限にとどめるのが望ましいでしょう。

第三に、ログイン情報を伴う通信の扱いです。認証済みの状態でデータをやり取りする場合、CORSの設定はより慎重さが求められます。この場合はワイルドカードでの許可が使えないなど、追加の考慮が必要になるため、認証を伴う連携があるかどうかを早めに共有しておくとよいでしょう。第四に、責任分界の明確化です。フロントエンドとAPIを別のベンダーや別のチームが担当している場合、CORSの設定を「どちらが」「どの環境で」持つのかを最初に決めておくと、エラー時のたらい回しを避けられます。開発中の一時的な回避策として、ローカルの開発サーバにプロキシを挟み、ブラウザから見て同一オリジンに見えるようにしてCORSを避ける方法が使われることもあります。ただしこれはあくまで開発時の便宜的な手段であり、本番環境で正しくオリジン間の連携を成り立たせるには、サーバ側で許可オリジンを適切に設定するのが本筋です。開発では動いたのに本番でエラーが出る、という前述の状況は、この回避策に頼ったまま本番の設定を用意し忘れたときにも起こります。回避策と本来の対応を混同しないことが、つまずきを減らすうえで役立つでしょう。

なお本記事は特定製品の設定手順ではなく、CORSという仕組みの考え方と運用で押さえたい観点に焦点を当てているものです。個別の実装を詰める段階では、利用するサーバやフレームワークの公式ドキュメント、実績のあるベンダーへの確認が別途必要になります。

まとめ

• CORSとは、別オリジンへのブラウザ経由のアクセスを、サーバの許可ヘッダで制御する仕組みです。
• ブラウザには同一オリジンポリシーという原則があり、CORSはそれに例外的な許可を与えて正規の連携を成り立たせます。
• 目的はサーバの保護ではなく、なりすまし等から利用者を守ることにあり、判断しているのはブラウザです。
• 書き換えを伴う通信ではプリフライト（事前確認）が行われ、その応答設定も必要になります。
• よくあるエラーの多くはサーバ側の許可設定で解決し、フロントだけを直しても収まらないことがあります。
• 運用では、許可オリジンの管理・範囲の最小化・認証を伴う通信の扱い・責任分界の明確化を押さえておくと安定します。
• 本記事は特定製品の設定手順ではなく、CORSという仕組みの考え方と運用の観点の整理を狙いとしています。

よくある質問

著者：テレリモ総研編集部　鈴木 亮佑

ご不明な点はお問い合わせフォームからもご連絡いただけます。

出典

• MDN Web Docs「オリジン間リソース共有 (CORS)」
• MDN Web Docs「同一オリジンポリシー」
• IETF「RFC 6454 The Web Origin Concept」

Tweet