ブラウザの門番CORSとワイルドカードの罠

Web開発中にあのコンソールで出くわす真っ赤なエラーメッセージ。今回はその正体である CORS（Cross-Origin Resource Sharing）について深掘りしていきます。 なぜ ブラウザ はリクエストを ブロック してしまうのか。その裏にあるブラウザの意図を理解するのが今回のミッションです。 この話の根底には、まず 同一オリジンポリシー という インターネットの大原則 があるんですよ。これはセキュリティの基本です。 データを取ってこれるのは 同じオリジン（場所）から来たものだけ というルールです。悪意のあるサイトから情報を抜き取られないための重要な仕組みです。 ブラウザ の立場からすると、知らない奴からのリクエストはまず疑ってかかる。かなり厳格な門番のような振る舞いをしているわけですね。 ドメイン が違ったり許可証がなかったりする相手には、データは一歩も通さない。一見過保護ですが、これでユーザーが守られています。 その厳格な門番をちゃんとした理由で通過するための許可証。それこそが CORS という クロスオリジン間でリソースを共有する仕組み です。 許可証の具体的な名前は Access-Control-Allow-Origin。これが サーバー からの 通行許可証そのもの と言えます。 実務でよくハマるのが許可証の書き方です。値に ワイルドカード の アスタリスク を指定すると、全オリジンからのアクセスが許可されます。 しかし、クッキー などの 認証情報 を含めたい場合、このワイルドカードは使えない という大きな落とし穴があります。 「誰でもOK」という許可証では 個人情報が関わる通信は許可しない という仕様です。これを知らずに開発で時間を溶かすケースは非常に多いです。 Google Apps Script（GAS）の コンテンツサービス も ヘッダー を自動で付けますが、認証が絡むとこれが壁になることがあります。 赤いエラーは単なる失敗ではなく、門番がセキュリティの不備を教えてくれている親切な警告 だったと捉えるのが、理解の近道かもしれません。 もし CORS という 防犯ゲートが全くなかったら、一つのサイトを開いただけでログイン中の全情報が抜き取られるリスクがあるのです。