Tech Learning Daily

同一オリジンポリシー — ブラウザだけが引く境界線

2 つの URL が「同じオリジン」と言えるのは、スキーム・ホスト・ポートの 3 つがすべて一致するときだけだ。https://app.example と https://api.example はホストが違うので別オリジン、https://app.example と http://app.example はスキームが違うので別オリジンになる。ブラウザはこの一致を確認し、異なるオリジンへの JavaScript からのリクエストで返ってきたレスポンスの中身を、呼び出し元のスクリプトに読ませないようにする——これが同一オリジンポリシーだ。

この制限が要るのは、ブラウザがリクエスト先のホストに紐づく Cookie を、そのリクエストを誰が発行したかに関係なく自動で付けて送るからだ。もし制限が無ければ、開いているだけの無関係なページの JavaScript が、あなたがログイン済みの銀行の API を裏で呼び出し、ログインセッションの Cookie に便乗して残高データを読み出せてしまう。同一オリジンポリシーは「送る」こと自体は止めず、「送った結果を読む」ことだけを塞いでいる。

CORS（Cross-Origin Resource Sharing）は、サーバーがこの制限を特定の相手にだけ解除してよいと宣言するための仕組みにすぎない。しかも判定と遮断はすべてブラウザの中で完結し、サーバーはただレスポンスヘッダーを返すだけで判定には関与しない。curl や Postman はブラウザの Cookie を共有せず、この判定ロジックも持たないので、サーバーが正しく動いていてもそのまま素通りする——「サーバー側は動いているのにブラウザだけ落ちる」現象の正体はここにある。

「シンプルリクエスト」はなぜ静かに素通りするのか

すべてのクロスオリジンリクエストがブラウザに止められるわけではない。メソッドが GET / HEAD / POST のいずれかで、ヘッダーが Accept や Content-Language など決められた安全なものだけ、かつ Content-Type が application/x-www-form-urlencoded ・ multipart/form-data ・ text/plain のいずれかであれば、それはシンプルリクエストとして扱われ、事前確認なしにそのまま送られる。

「CORS エラーが出た＝リクエストはサーバーに届いていない」と考えたくなる。しかし実際は、シンプルリクエストの場合サーバーは処理を最後まで終えている。ブラウザは裏でリクエストを送信し、サーバーはそれを受け取って通常どおり処理し、レスポンスも返す。CORS が塞ぐのはその後の一手だけで、返ってきたレスポンスの中身を JavaScript に渡さずに握りつぶす。副作用のある GET リクエストを不用意に置いてはいけない理由がここにある。

逆に言えば、モダンな JSON API の POST/PUT/DELETE がほぼ必ずブラウザの Network タブに OPTIONS を出しているのは偶然ではない。Content-Type: application/json は安全なリストに含まれていないため、JSON を送る時点でシンプルリクエストの条件から外れ、次に説明する事前確認の対象になる。データを書き換える操作の大半が自然とこの仕組みの内側に入る設計になっている。

プリフライト — 実行前にサーバーへ確認を取る

シンプルリクエストの条件から外れるリクエストを送ろうとすると、ブラウザは本番のリクエストの前に OPTIONS メソッドのプリフライトリクエストを自動で送る。ここには「これから POST を送りたい」という Access-Control-Request-Method と、使うヘッダーを申告する Access-Control-Request-Headers が乗る。サーバーが Access-Control-Allow-Origin ・ Access-Control-Allow-Methods ・ Access-Control-Allow-Headers で許可を返して初めて、ブラウザは本番のリクエストを送信する。

Browser                 Server
  │ OPTIONS（確認）         │
  ├────────────────────────▶│
  │ 204 + Allow-Origin 等    │
  │◀────────────────────────┤
  │ POST（本番リクエスト）     │
  ├────────────────────────▶│
  │ 200 OK + データ          │
  │◀────────────────────────┤

この往復は毎回発生すると無駄なので、サーバーは Access-Control-Max-Age で確認結果をブラウザにキャッシュさせられる。設定しない場合のデフォルトは 5 秒で、同じエンドポイントへの連続リクエストのたびに往復が積み重なる。長く指定すればキャッシュは効くが、ブラウザ側にも上限があり、それを超えて指定しても切り詰められる（Chromium は v76 以降で 7200 秒＝2 時間、Firefox は 86400 秒＝24 時間が上限）。

Credentials と Access-Control-Allow-Origin: * の非互換

不特定多数に公開する API は Access-Control-Allow-Origin: * を返しておけば、どのオリジンから呼ばれても手間なく許可できる。しかしリクエストが Cookie や TLS クライアント証明書などの資格情報を伴う場合、ブラウザはこのワイルドカードを拒否する。サーバーは呼び出し元のオリジンを https://app.example のように名指しで返し、加えて Access-Control-Allow-Credentials: true を返さない限り、リクエスト自体は成功していてもレスポンスは JavaScript に渡らない。

クライアント側にも対の設定が要る。fetch で credentials: "include" を指定しない限り、そもそもクロスオリジンの Cookie は送られない。「サーバー側は名指しでオリジンを許可した、クライアント側も credentials を指定した」の両方が揃って初めて、ログイン状態を保ったクロスオリジン API 呼び出しが成立する。