【ITニュース解説】If a backend endpoint is public (allowed from any origin), browsers don’t send cookies by default. And if you try to send cookies, you’ll likely face a CORS error unless the backend is properly configured. I wrote a full blog with details 👇

システムエンジニアを目指す上で、Webアプリケーションがどのように情報をやり取りし、セキュリティを保っているかを理解することは非常に重要だ。今回取り上げるニュース記事の主題は、ブラウザが異なるWebサイト（オリジン）間でCookieを扱う際の挙動、特に「公開されたバックエンドエンドポイントに対しては、デフォルトでCookieを送信しない」というものだ。そして、もしCookieを送信しようとすると、設定が不適切であればCORSエラーが発生する可能性が高い。この挙動は、Webセキュリティの根幹をなす「同一オリジンポリシー」と「CORS」という仕組みに深く関連しており、Web開発に携わる上で避けては通れない知識と言える。

まず、Cookieとは何かを説明する。Cookieは、Webサイトがユーザーのブラウザに保存する小さなテキストファイル形式の情報のことだ。これには、ユーザーのログイン状態、ショッピングカートの中身、サイト設定の好み、閲覧履歴など、様々な情報が含まれる。Webサイトは、このCookieを使ってユーザーを識別し、状態を維持することで、パーソナライズされた快適な体験を提供する。例えば、一度ログインすれば次回以降はIDやパスワードを入力しなくてもサイトにアクセスできるのは、Cookieがログイン情報を保持しているためだ。

次に、Webアプリケーションがどのようにサーバーと通信するかを見てみよう。Webアプリケーションは、通常、ユーザーインターフェースを提供する「フロントエンド」と、データ処理やビジネスロジックを実行する「バックエンド」に分かれている。フロントエンドはブラウザ上で動作し、バックエンドはサーバー上で動作する。フロントエンドがバックエンドの機能を利用する際には、「APIエンドポイント」という窓口を通じてリクエストを送信する。エンドポイントとは、サーバー上にある特定の機能やデータにアクセスするためのURLのことだと考えてほしい。

そして、「オリジン」という概念がここで重要になる。オリジンとは、Webサイトの「発行元」を識別するための要素で、具体的には「プロトコル（httpやhttps）」「ホスト（ドメイン名やIPアドレス）」「ポート番号」の3つがすべて一致する場合に「同一オリジン」と判断される。例えば、https://example.com:443とhttps://api.example.com:443はドメインが異なるため、別のオリジンとなる。ブラウザは、このオリジンに基づいて、Webページの動作に強いセキュリティ制約を課している。これが「同一オリジンポリシー」だ。

ニュース記事が指摘する「公開されたバックエンドエンドポイント（どのオリジンからも許可されている場合）」とは、特定のオリジンからのアクセスを制限せず、あらゆるWebサイトからのリクエストを受け入れるように設定されたAPIのことだ。しかし、このようなエンドポイントに対して、ブラウザはデフォルトではCookieを送信しない。これはなぜか。ブラウザは、悪意のあるWebサイトが、ユーザーがログインしている別のWebサイトのCookieを不正に利用して、ユーザーになりすまして操作することを防ぐために、自動的にCookieを送信しないようになっているのだ。もしブラウザが常にCookieを自動送信してしまうと、ユーザーが悪質なサイトを閲覧しただけで、そのサイトがユーザーの意図しないまま、別の重要なサイト（例えば銀行サイト）にログインし、情報を盗み取ったり、不正な操作を行ったりするリスクが発生してしまう。これをCSRF（クロスサイトリクエストフォージェリ）攻撃などと呼ぶ。ブラウザのこのデフォルトの挙動は、このような攻撃からユーザーを守るための重要なセキュリティ対策だ。

では、もしフロントエンドがバックエンドのAPIに対してCookieを含んだリクエストを送信したい場合はどうすればよいのか。例えば、ユーザーがログインしている状態を維持したまま、異なるオリジンのAPIからユーザー固有のデータを取得したい場合などがこれに該当する。この時、もしバックエンドが適切に設定されていないと、「CORSエラー」に直面することになる。

CORS（Cross-Origin Resource Sharing）、日本語で「クロスオリジンリソース共有」とは、ブラウザが持つ「同一オリジンポリシー」というセキュリティ制約を、Webサーバーが明示的に許可することで、異なるオリジン間で安全にリソース（データなど）を共有できるようにする仕組みのことだ。デフォルトでは、異なるオリジンからのリクエストはセキュリティ上の理由でブロックされるが、CORSは、サーバーが「このオリジンからのアクセスは許可します」とブラウザに伝えることで、このブロックを解除する役割を果たす。

Cookieを含んだクロスオリジンリクエストは、通常のクロスオリジンリクエストよりもさらに厳密なCORSの設定が必要となる。これは、Cookieがユーザーの認証情報やセッション情報といった機密性の高いデータを含んでいるためだ。ブラウザは、Cookieを含むクロスオリジンリクエストを送信する際、バックエンドサーバーが特定のCORSヘッダーをレスポンスに含めているかどうかを厳しくチェックする。

具体的には、バックエンドサーバーは、以下の2つのCORSヘッダーをレスポンスに含める必要がある。

1. Access-Control-Allow-Origin: リソースへのアクセスを許可するオリジンを指定する。例えば、Access-Control-Allow-Origin: https://frontend.example.comのように、許可するフロントエンドのオリジンを明示的に指定する必要がある。セキュリティ上の理由から、Cookieを伴うリクエストの場合、この値にワイルドカード*（すべてのオリジンを許可）を使用することはできない。特定のオリジンを明確に指定しなければならない。
2. Access-Control-Allow-Credentials: true: Cookieなどの認証情報をリクエストに含めることを許可するかどうかをブラウザに伝えるためのヘッダーだ。このヘッダーがtrueに設定されていない場合、ブラウザはCookieを含んだクロスオリジンリクエストをブロックし、CORSエラーを発生させる。

つまり、ニュース記事が指摘する「バックエンドが適切に設定されていない限り」という状況は、これらのCORSヘッダー、特にAccess-Control-Allow-Credentials: trueがレスポンスに含まれていない場合を指す。フロントエンドの開発者が、JavaScriptのfetch APIやXMLHttpRequestでリクエストを送信する際にcredentials: 'include'といったオプションを指定してCookieを含めようとしても、バックエンドが上記のCORSヘッダーを正しく設定していなければ、ブラウザはセキュリティ上の理由からリクエストをブロックし、CORSエラーとして報告するのだ。

この一連の挙動を理解することは、システムエンジニアとしてWebアプリケーションを開発する上で非常に重要だ。単に「CORSエラーが出たから設定を適当にいじる」のではなく、「なぜこのエラーが発生するのか」「ブラウザが何を守ろうとしているのか」「サーバー側でどう設定すれば安全に通信できるのか」といった背景を深く理解することで、セキュリティを考慮した堅牢なWebアプリケーションを設計・実装できるようになる。Web開発では、フロントエンドとバックエンドの連携が不可欠であり、その中でのCookieの扱い、そしてセキュリティメカニズムである同一オリジンポリシーやCORSの理解は、安定した安全なサービスを提供するための基礎となる知識だ。特に、認証やセッション管理に関わる部分では、この知識が不可欠である。