本文へスキップ
>_ITDITDセキュリティ対策プラットフォーム

用語辞典

#CORS#脆弱性#Web

CORSとは — 仕組みと、設定ミス（CORS misconfiguration）で起きること

CORS（オリジン間リソース共有）は、あるサイトのJavaScriptが別オリジンのAPI応答を読めるかをブラウザが制御する仕組みです。設定を緩くしすぎる『CORS設定ミス』があると、第三者サイトからログイン済みのデータを読まれることがあります。仕組みと、安全な設定（許可リスト・Originを反射しない・* と認証情報を併用しない）を防御目線で解説します。

公開日 2026-06-11 更新日 2026-06-11 5分で読める

「APIに Access-Control-Allow-Origin を付けたら動いたけど、これ安全？」——CORSは“付ければOK”ではなく、許可する相手を絞るのが肝です。仕組みと安全な設定を解説します（攻撃手順は載せません）。

まず仕組み

ブラウザには「別オリジンのJSは勝手に他サイトの応答を読めない」という同一オリジンポリシーがあります。CORSは、その例外をサーバーが明示的に許可した相手にだけ開くためのものです。

応答ヘッダ意味
Access-Control-Allow-Originどのオリジンに応答の読み取りを許すか
Access-Control-Allow-CredentialsCookie等の認証情報を伴う通信を許すか
Access-Control-Allow-Methods / -Headers許可するHTTPメソッド/ヘッダ

ポイントは、CORSは「制限を緩める」側の仕組みだということ。緩め方を間違えると、本来読めないはずのデータが第三者に読めてしまいます。

何が危ない設定か

危険な設定（やりがち）

  • リクエストの Origin をそのまま反射して許可する
  • Access-Control-Allow-Origin: * ＋ 認証情報も許可
  • 必要のないAPIまで広く別オリジンに開放

安全な設定

  • 許可リスト（信頼できる固定のオリジンだけ）
  • それ以外は既定で拒否
  • 認証情報を伴うなら * を使わず具体的なオリジンを指定
攻撃者サイトのJSが、あなたのAPIへリクエスト（利用者はログイン中）
↓ サーバーがOriginを鵜呑みに許可（設定ミス）
ブラウザが応答の読み取りを許す＝個人情報/トークンが攻撃者サイトに渡る
緩い設定だと、攻撃者サイトのJSが利用者のログイン状態を使ってAPIの応答を読めてしまう。

安全な設定の基本

1

許可リスト方式にする（最重要）

あらかじめ決めた信頼できるオリジンだけを許可し、それ以外は拒否（既定で拒否）。「とりあえず全部許可」をしない。
2

Originを鵜呑みに反射しない

リクエストの Origin をそのまま Access-Control-Allow-Origin に echo しない。許可リストと突き合わせて一致したときだけ返す。
3

認証情報を伴うなら * を使わない

Cookie等を伴う通信で Access-Control-Allow-Origin: * と Allow-Credentials: true を併用しない。具体的なオリジンを指定する。
4

開く範囲を最小に

別オリジンに公開する必要があるエンドポイントだけを対象にする。広く開けない。設定はセキュリティヘッダ診断等で確認する。

当サイトの視点：CORSは『守り』ではなく『緩め方』。緩める相手を絞る

よくある誤解は「CORSヘッダを付ければ安全になる」です。逆で、CORSはブラウザの制限を“緩める”側の仕組み。だから安全のコツは「どう付けるか」より「誰に・どこまで開けるかを最小に絞る」ことです。当サイトは、外部から読めてよいデータと、そうでないデータを分け、既定で拒否・許可リストで例外だけ開ける方針を勧めています。なお、応答を読まれる前提が崩れる XSS や、状態変更を狙う CSRF は別の脆弱性なので、CORSだけで全部が守れるわけではありません。

次に読む

よくある質問

QCORSは何のための仕組みですか？
A

ブラウザには『別のオリジン（サイト）のJavaScriptは、勝手に他サイトの応答を読めない』という同一オリジンポリシーがあります。CORS（Cross-Origin Resource Sharing）は、その例外を“サーバーが明示的に許可した相手にだけ”開くための仕組みです。Access-Control-Allow-Origin などの応答ヘッダで、どのオリジンに応答の読み取りを許すかを宣言します。

QCORSの設定ミスで何が起きますか？
A

許可を緩くしすぎると、攻撃者のサイトのJavaScriptから、利用者のログイン済みAPIの応答を読まれる恐れがあります。典型例は、リクエストのOriginをそのまま反射して許可する設定や、Access-Control-Allow-Origin を * にしつつ認証情報（Cookie等）も許可してしまう設定です。結果として個人情報やトークンが第三者サイトに渡り得ます。

Q安全な設定の基本は？
A

『許可リスト方式』です。あらかじめ決めた信頼できるオリジンだけを許可し、それ以外は拒否（既定で拒否）。リクエストのOriginを鵜呑みに反射しない。認証情報を伴う通信では Access-Control-Allow-Origin に * を使わず、具体的なオリジンを指定する。そもそも別オリジンに公開する必要があるエンドポイントだけを対象にする、のが基本です。