CORS設定ミスとは？起きるパターンと対策法

CORS設定ミスとは？起きるパターンと対策法

#セキュリティ#Web開発#脆弱性対策

CORS設定ミスは、ブラウザの同一オリジンポリシーを緩める設定を誤り、他サイトから認証付きのデータを読まれる脆弱性です。 対策の勘所は、アクセスを許すオリジンを明示的な許可リストで管理できているかどうかです。

CORS設定ミスとは

CORS設定ミス（CORS misconfiguration）：クロスオリジンからのアクセスを許可するCORSの設定を誤り、本来読ませるべきでないオリジンにレスポンスを読ませてしまう脆弱性です。 許可するオリジンを緩く設定することが根本原因になります。

ブラウザは通常、別オリジンのレスポンスをスクリプトから読めないよう制限します。 CORSはこれを意図的に緩める仕組みで、設定を誤ると攻撃者のサイトからログイン中の利用者のデータを読み取られ、情報漏洩に至ります。 CORSの制約を満たす単純リクエストは、サーバがレスポンスの読み取りを許可していなくても送信されます。 一方、非単純リクエストではブラウザが事前にpreflightリクエストを送り、サーバの許可を確認できなければ実際のリクエストを送りません。

CORS設定ミスが起きるパターン

典型的な弱点は次のとおりです。

  • リクエストのOriginヘッダを無条件にAccess-Control-Allow-Originの具体値として反映し、Access-Control-Allow-Credentials: trueも返している
  • 許可オリジンの判定を部分一致で行い、example.com.attacker.comのような偽装を通してしまう
  • 開発時の緩い設定（全許可）を、本番までそのまま持ち込んでいる
  • nullオリジンを許可し、サンドボックス化されたページからのアクセスを通す

共通するのは「アクセスを許すオリジンを絞り込まず、Cookieなどの認証情報が送信される条件を満たしたときに、攻撃者のサイトにもレスポンスを読ませてしまう」という点です。 なお、Access-Control-Allow-Origin: *とAccess-Control-Allow-Credentials: trueを同時に返しても、ブラウザは認証情報を含むレスポンスをスクリプトへ公開しません。 認証情報を伴うアクセスで危険なのは、攻撃者のOriginをワイルドカードではなく具体値として許可してしまう設定です。

対策法

原則は「アクセスを許可するオリジンを明示的な許可リストで限定する」ことです。

  • 許可するオリジンをホワイトリストで管理し、一致した場合だけAccess-Control-Allow-Originに具体的な値を返す。これが本命の対策になる
  • 認証情報を伴うアクセスではワイルドカード（*）を使わず、許可したオリジンだけを具体値で返してAccess-Control-Allow-Credentials: trueを設定する
  • リクエストのOriginを無条件に反射せず、必ず許可リストと照合する
  • オリジンの照合は完全一致で行い、部分一致やnullの許可を避ける
  • 本番と開発で設定を分け、緩い設定を本番に持ち込まない

Originの反射や全許可は攻撃の入り口になるため、許可リストへの置き換えが最優先です。 許可オリジンを一元管理し、認証付きエンドポイントから見直すのが費用対効果の高い進め方になります。

Rails での事例

Rails では CORS の設定を rack-cors ミドルウェアで行うのが一般的です。 設定ミスの典型は、正規表現による部分一致です。

# 危険：アンカーのない正規表現は部分一致になる
# "https://example.com.attacker.net" や "https://evil-example.com" も通る
Rails.application.config.middleware.insert_before 0, Rack::Cors do
  allow do
    origins /example\.com/
    resource "/api/*", headers: :any, methods: [:get, :post], credentials: true
  end
end

許可オリジンは文字列の完全一致で列挙します。 正規表現を使う必要があるときも、\A と \z でアンカーし、ドットをエスケープします。

Rails.application.config.middleware.insert_before 0, Rack::Cors do
  allow do
    origins "https://app.example.com", "https://admin.example.com"
    resource "/api/*", headers: :any, methods: [:get, :post, :put, :delete], credentials: true
  end
end

origins にブロックを渡して常に true を返す実装は、リクエストのOriginを具体値として無条件に許可するのと同じであり、許可リストの意味がなくなります。 この実装をcredentials: trueのエンドポイントに適用すると、Cookieなどの認証情報が送信される条件を満たした攻撃元にもレスポンスの読み取りを許します。 なお、フロントエンド側（React など）に CORS を「直す」手段はありません。 開発中に CORS エラーへ遭遇したとき、ブラウザ側の回避策を探すのではなく、サーバ側の許可リストに正規のオリジンを追加するのが正しい対処です。

まとめ

CORS設定ミス対策の要点を整理します。

  • 根本原因は「許可するオリジンを絞り込んでいないこと」であり、単純リクエストは読み取りが許可されていなくても送られる一方、非単純リクエストはpreflightで許可されなければ実際のリクエストが送られない
  • 本命の対策は許可リストによるオリジンの限定。一致した場合だけAccess-Control-Allow-Originに具体的な値を返す
  • Access-Control-Allow-Origin: *では認証情報を含むレスポンスを読めないため、危険なのは任意のOriginを具体値として反射し、Access-Control-Allow-Credentials: trueも返す設定
  • 照合は完全一致で行う。rack-corsでアンカーのない正規表現（/example\.com/）を使うと部分一致になり、https://example.com.attacker.netまで通る
  • 開発時の緩い設定を本番へ持ち込まない。nullオリジンの許可も避ける

フロントエンド側にCORSを「直す」手段はありません。 開発中にCORSエラーへ遭遇したとき、ブラウザ側の回避策を探すのは誤りで、サーバ側の許可リストに正規のオリジンを追加するのが正しい対処です。

関連して読める記事

CORSはブラウザが持つオリジンの境界を意図的に緩める仕組みで、その境界の上に成り立っている防御はほかにもあります。 CSRFはCookieの自動送信という境界のゆるさを突く攻撃であり、クリックジャッキングは表示の境界（フレーム）を突く攻撃です。 3つを並べると、ブラウザ側の境界がどこで何を守っているかが整理できます。 読み取られる中身が機微であるほど被害が大きくなる点では、XSSとも地続きです。

CSRF（クロスサイトリクエストフォージェリ）とは？起きるパターンと対策法

CSRF（クロスサイトリクエストフォージェリ）の仕組みと起きるパターン、CSRFトークンとSameSite Cookieを軸にした対策を整理します。Railsで検証を外してしまう skip_before_action の罠と、React（TypeScript）からのトークン送信ヘッダの組み込み方を、危険なコードと安全な書き方の具体例で示します。

2026年7月23日

クリックジャッキングとは？起きるパターンと対策法

クリックジャッキングの仕組みと起きるパターン、CSP の frame-ancestors と X-Frame-Options を軸にした対策を整理します。Rails が既定で付ける SAMEORIGIN を埋め込み対応のために削除してしまう危険例と、許可先を列挙する正しい設定、重要操作に確認を挟む設計を具体的なコードで示します。

2026年7月25日

XSS（クロスサイトスクリプティング）とは？起きるパターンと対策法

XSS（クロスサイトスクリプティング）の仕組みと3つの型、混入しやすいパターン、そして出力時のエスケープを軸にした対策を整理します。React（TypeScript）の dangerouslySetInnerHTML と Rails（ERB）の raw / html_safe を題材に、危険なコードと安全な書き方を具体的なコード例で示します。

2026年7月22日
この記事をシェア