ひとことで言うと
CORSは、あるドメインのページが別のドメインへリクエストを送ってよいかどうかを、ブラウザとサーバーが確認し合う仕組みです。
たとえば app.example.com のページが api.other.com へデータを取りに行こうとしたとき、ブラウザは「本当に許可されているか？」をサーバーに確認します。
サーバーが「許可する」と返せばデータを受け取れますが、何も答えなければブラウザがその通信をブロックします。
たとえ話でもう少し詳しく
CORSは、マンションの入館ルールに近いです。
- 自分の部屋（同じドメイン）には自由に出入りできる
- 隣の棟（別のドメイン）へ入るには、管理組合の許可が必要
- 許可証（レスポンスヘッダー）を持っていれば入れる、なければ入口で止められる
ブラウザは同じドメイン内の通信は自由に許しますが、別ドメインへの通信にはこのチェックを挟みます。 これは悪意のあるサイトが勝手に別サービスのAPIを呼び出してデータを抜き取るのを防ぐためのブラウザの安全機能です。 サーバー側で「このドメインからの通信は許可する」と明示することで、正規のアプリだけが通信できるようになります。
よく出る場面・使いどころ
- フロントエンドとバックエンドを別ドメインで運用しているとき
- 自社サービスのAPIを特定のパートナーサイトだけに公開したいとき
- 開発中にローカル環境（localhost）から本番APIを呼び出したいとき
- ブラウザのコンソールに「CORSエラー」と出て通信が止まったとき
似た言葉との違い
- 認証
- 「誰が」アクセスしているかを確認する仕組み
- CORSは「どのドメインから」の通信を許可するかを制御する仕組み
- WAF
- 危険なリクエストをサーバー側でフィルタリングする仕組み
- CORSはブラウザが行うドメイン間通信の制御で、サーバーへ届く前の段階で働く
- HTTP
- ブラウザとサーバーの通信ルール
- CORSはHTTPのヘッダーを使って許可の有無をやりとりする
実務で気にするポイント
- 許可するドメインは必要最小限にする（
*で全許可にしない） - 認証情報（Cookieなど）を含む通信は、追加の設定が必要
- プリフライトリクエスト（事前確認）が発生する場合、サーバーの応答速度に影響する
- 開発環境と本番環境で許可するドメインが異なるため、環境変数で切り替える
注意: CORSはブラウザの安全機能です。サーバー同士の通信（バックエンド間のAPI呼び出しなど）には適用されません。「CORSを無効にする」という対応は問題を根本解決せず、セキュリティを下げるだけなので避けましょう。