はじめに
CORSのエラーは、開発中に一度は突き当たる壁です。ブラウザのコンソールに赤字で表示されるあのメッセージを消したい一心で、深く考えずにヘッダーを緩めてしまった経験がある方も多いのではなでしょうか。
厄介なのは、実装によっては個人情報や認証情報の漏えいにつながり得る点です。
しかも大手サービスや政府機関のサイトでも同様の設定不備が報告されており、決して他人事ではありません。
この記事では、CORSの仕組みを簡単におさらいした上で、実際に事故につながった設定ミスのパターンと、その対策を整理します。
本記事の内容は2026年9月時点の情報をもとにしています。仕様は更新される可能性があるため、実装時は必ずMDNなど公式ドキュメントもあわせてご確認ください。
CORSとは何か
CORS（Cross-Origin Resource Sharing）は、ブラウザの「同一オリジンポリシー」を、サーバー側の許可のもとで安全に緩和する仕組みです。
同一オリジンポリシーは、あるWebサイトが別のオリジン（ドメイン・ポート・プロトコルのいずれかが異なるサイト）のリソースに自由にアクセスできないようにする、ブラウザ標準のセキュリティ機能です。
APIを外部サイトから呼び出してもらいたい場合など、正当な理由でこの制限を緩めたいケースがあります。そのために使われるのがCORSであり、サーバーがレスポンスヘッダーで「このオリジンからのアクセスは許可します」と明示的に伝える仕組みになっています。
やりがちな設定ミス3パターン
1. ワイルドカード＋認証情報の組み合わせ
もっとも多いのが、次のような設定です。
Access-Control-Allow-Origin: *
Access-Control-Allow-Credentials: true
この組み合わせはブラウザの仕様上そもそも成立しません。 Access-Control-Allow-Credentials: trueを指定する場合、Access-Control-Allow-Originにワイルドカードは使えず、具体的なオリジンを1つ返す必要があります。
ブラウザはこの組み合わせを検出するとエラーにし、認証付きリクエストのレスポンスをJavaScriptから利用できないようにします（MDNでも明記されている挙動です）。
つまりこの組み合わせ自体が直接個人情報漏えいを引き起こすわけではありません。
ただし、この設定を書いている時点で「オリジンを絞る」という意識が抜けているサインではあり、次に紹介する本当に危険なパターンとセットで発生しやすいので注意が必要です。
2. Originヘッダーの値をそのまま反射させる
エラー回避のために、リクエストのOriginヘッダーの値をそのままAccess-Control-Allow-Originに返す実装です。
Access-Control-Allow-Origin: (リクエストのOriginをそのまま返す)
このような実装では、攻撃者が用意した任意のオリジンが許可される状態になり得ます。
さらにAccess-Control-Allow-Credentials: trueを同時に返している場合、認証情報を含むリクエストのレスポンスを、そのオリジンのJavaScriptから読み取れる状態になる可能性があります。
そのため、認証が必要なAPIでは、許可するオリジンを事前に定めたホワイトリストと照合して判定する必要があります。
許可するオリジンは、事前に決めたホワイトリストと突き合わせて判定する必要があります。
3. nullオリジンの許可
Access-Control-Allow-Origin: null
file://から開いたページやsandbox化されたiframeなどは、Originがnullになることがあります。
このnullを安易に許可してしまうと、攻撃者が意図的にnullオリジンを作り出してアクセスしてくる可能性があります。nullは許可リストに含めないのが基本です。
実際に起きた事故の例
「理論上危険」なだけでなく、CORS設定不備は実際に大手サービスでも報告されています。バグバウンティプラットフォームHackerOneで公開されている事例を5つ紹介します。
1. Zomato（レストラン検索サービス）
インドの大手レストラン検索サービスZomatoでは、zomato.comのサブドメインからのアクセスを許可する設定のはずが、判定ロジックの不備により「zomato.comで終わるドメインすべて」を許可してしまっていました。
この結果notzomato.comのような紛らわしいドメインを取得するだけで、他ユーザーのアカウント情報を読み取れる状態になっていたと報告されています。
2. Rockstar Games（ゲーム会社サポートサイト）
Rockstar GamesのサポートサイトにあったAPIゲートウェイでは、CORS設定の不備によってユーザーのメールアドレスやIDなどの情報が本来意図しない形で外部に共有されてしまう状態でした。
この問題は報告後、該当のゲートウェイ自体を廃止する形で対応されています。
3. 米国防総省（DoD）が運用するWebサイト
米国防総省の脆弱性報告プログラムでは、あるWebサイトでAccess-Control-Allow-OriginにリクエストのOriginヘッダーの値をそのまま反射し、かつAccess-Control-Allow-Credentials: trueを返す設定不備が報告されました。
政府機関のサイトであっても、この種のミスが起こり得ることを示す例として扱われています。
4. LY Corporation（LINEヤフー）
LY Corporationが運営する学習コミュニティ向けAPIサーバーでも、CORS設定不備が報告されています。
同一オリジンポリシーを回避できる状態になっており、本来はアクセスできないはずのプロフィール情報がAPI経由で取得できる状態でした。
別の不備と組み合わせることで、悪意あるWebページのリンクをユーザーがクリックしただけで個人情報が渡ってしまう仕組みになっていたと説明されています。
5. UPchieve（オンライン学習支援の非営利団体）
無料のオンライン学習支援サービスを提供するUPchieveでも、Originヘッダーの検証が不十分なままCredentials: trueを返す設定になっていました。
この状態では、任意のWebサイトがユーザーの認証情報付きでリクエストを送信し、レスポンスを読み取れてしまいます。教育分野の非営利サービスであっても、CORS設定は同じリスクを抱えることを示す例です。
実際に起きる被害
CORS設定不備が実害につながるのは、攻撃者が指定したオリジンから認証情報付きのリクエストを送信でき、かつそのレスポンスを読み取れる状態になっている場合です。
この条件がそろうと、次のような被害につながる可能性があります。
- ログイン中のユーザーが悪意あるサイトを訪問した際、別サイトの個人情報が読み取られる
- 本来そのオリジンには公開していないAPIのレスポンスが読み取られる
- ユーザー権限で取得できる情報が、攻撃者側のWebページから取得される
なお、Cookieを使ったセッション管理の場合はSameSite属性やブラウザの第三者Cookie制限なども影響するため、「CORS設定に不備があれば必ず情報が漏えいする」というわけではありません。
ただし、これらの追加対策に頼るのではなく、CORS設定そのものを正しく行うことが基本です。
主な対策
基本方針は「必要なオリジンだけを、明示的に許可する」の一言に尽きます。
- 許可するオリジンをホワイトリストで管理し、完全一致で判定する
-
Access-Control-Allow-Originにワイルドカードを使うのは、認証情報を使わない公開APIに限定する - Cookieでセッション管理している場合は
SameSite属性も併用し、CORS設定に不備があった場合の被害を抑える - 定期的に設定を見直し、不要になったオリジンは削除する
まとめ
CORSは「エラーを消すための設定」ではなく、「どのオリジンにどこまでアクセスを許可するか」を決めるセキュリティ設定です。
- ワイルドカードと認証情報の組み合わせはブラウザの仕様上エラーになり、直接の漏えい原因にはならない
- 本当に危険なのはOriginヘッダーの値をそのまま反射させるパターンで、認証情報付きレスポンスを攻撃者側から読み取られる可能性がある
-
nullオリジンは安易に許可しない - オリジンはホワイトリストで厳格に管理する
「とりあえず動かす」ための設定が、そのまま個人情報漏えいの入り口になってしまうこともあります。実装前にひと呼吸置いて、許可するオリジンを見直してみてください。