Origin は、スキーム・ホスト・ポートの3つ組で表される Web 上の識別単位です。 CORS や Same-Origin Policy は、すべてこの単位で「同じ場所か・別の場所か」を判定しています。
具体例で見るとすぐ分かる
https://example.com/page を基準にしたとき、次のようになります。
| 相手 | 判定 | 理由 |
|---|---|---|
https://example.com/other |
同一 | パスは関係ない |
http://example.com |
別 | スキームが違う |
https://www.example.com |
別 | ホスト名が違う |
https://example.com:8443 |
別 | ポートが違う |
https://api.example.com |
別 | サブドメインは別ホスト |
「同じドメインだから大丈夫」という感覚がいちばん危ないところです。www の有無、http と https、ポート違いはすべて別オリジンとして扱われます。
開発環境で必ずぶつかる
localhost:3000 のフロントから localhost:8000 の API を呼ぶ構成は、ホストが同じでもポートが違うので別オリジンです。ローカルで CORS エラーが出る原因のほとんどがこれです。
逆に、本番でフロントと API を同じドメイン配下（example.com と example.com/api）にまとめると、そもそも別オリジンにならないため CORS の設定自体が不要になります。構成を決める段階で意識しておくと、あとの設定が減ります。
Origin ヘッダーの性質
ブラウザはクロスオリジンのリクエストに Origin ヘッダーを自動で付けます。パスやクエリを含む Referer と違い、Origin は3つ組だけなので送信元の秘密が漏れにくい作りです。
また、ブラウザが付けるものなのでサーバー側から見ると偽装できない相手（ブラウザ経由である限り）です。この性質を利用して、Streamable HTTP の MCP サーバーは Origin 検証を必須にしています。ただし curl などブラウザ以外からのリクエストには適用されない点は理解しておく必要があります。
実務で見るポイント
- 許可オリジンは環境ごとに列挙する。開発と本番で同じ設定を使い回さない
- サブドメインを増やす設計は、CORS 設定も増える設計だと理解しておく
- 証明書の話（https 化）とセットで、スキーム変更が別オリジン化を招く点に注意