『CORS エラー』は理解すれば怖くない
CORS (Cross-Origin Resource Sharing) は Web 開発で頻出するブラウザのセキュリティ機構です。本記事では編集部の視点で、仕組みと設定を公開情報をもとに整理します。Web セキュリティ実践 もご参考に。
CORS の基本
(1) Same-Origin Policy：ブラウザの基本ルール。(2) Origin = protocol + host + port。(3) CORS は緩和ルール：明示的に許可する仕組み。(4) サーバー側で許可：レスポンスヘッダで。(5) ブラウザのみ強制：curl 等は影響なし。
simple vs preflighted リクエスト
(1) simple：GET/POST/HEAD + 限られたヘッダ。(2) preflighted：上記以外。OPTIONS が事前送信。(3) preflight 結果のキャッシュ：Access-Control-Max-Age。(4) preflight の発生条件を理解。(5) 不要な preflight を減らす：パフォーマンス。
主要ヘッダ
(1) Access-Control-Allow-Origin：許可Origin。(2) Access-Control-Allow-Methods：許可メソッド。(3) Access-Control-Allow-Headers：許可ヘッダ。(4) Access-Control-Allow-Credentials：Cookie送信許可。(5) Access-Control-Max-Age：preflight キャッシュ秒数。
credentials の扱い
(1) fetch credentials: "include"：Cookie 送信。(2) Allow-Origin に wildcard 使用不可。(3) Allow-Credentials: true必須。(4) Cookie の SameSite属性。(5) セキュリティリスクを理解して使う。認証・認可実践 もご参考に。
サーバー側実装例
(1) Express：cors ミドルウェア。(2) Nginx：add_header CORS。(3) Cloudflare Workers：手動でヘッダ追加。(4) AWS API Gateway：CORS 設定タブ。(5) 動的判定：Origin リストで照合。API Gateway 実践 もご参考に。
本番運用のポイント
(1) wildcard "*" の使用回避：許可リスト方式。(2) 環境別の許可Origin：dev/stg/prd で違う。(3) preflight キャッシュ：性能改善。(4) 監視：CORS エラーログ。(5) ドキュメント化：API 利用者向け。
失敗しがちなパターン
(1) Origin の許可漏れ：ステージング忘れ。(2) credentials + wildcard：そもそも動かない。(3) preflight キャッシュ未設定：性能低下。(4) セキュリティ緩和：reflect 方式の濫用。(5) ローカル開発で disable：本番で動かない。対策は、(1)許可リスト管理、(2)固定 Origin、(3)Max-Age 86400、(4)厳格な検証、(5)dev/prd で同じ設定方式、です。