CORS設定ミス こーすせっていみす
簡単に言うとこんな感じ！
Webサービスが「どのサイトからのアクセスを許可するか」を決めるルールが「CORS」なんだ。設定ミスをすると、悪意あるサイトが「正規のサービスのふりをして」あなたの個人データをこっそり盗み見できちゃう状態になるよ。鍵をかけ忘れた金庫みたいなものだね！
CORS設定ミスとは
CORS（Cross-Origin Resource Sharing：オリジン間リソース共有）とは、あるWebサイトが「別のドメインにあるサーバー」へデータを取りに行くときのルールを定める仕組みです。ブラウザには本来「Same-Origin Policy（同一オリジンポリシー）」という安全機能があり、異なるドメインへの通信を原則ブロックします。CORSはこの制限を「条件付きで緩める」ための公式な抜け道です。
CORS設定ミスとは、このルールの設定が甘くなりすぎてしまった状態のことです。「どこからでもアクセスしていいよ」「リクエスト元が何を言っても許可するよ」という設定にしてしまうと、攻撃者が用意した悪意あるWebサイトから、ログイン済みユーザーの個人情報・APIレスポンス・セッション情報を盗み取れてしまいます。
特にシステム発注・選定をする立場では、「APIサーバーのCORS設定を開発者任せにしたまま本番リリースしてしまった」というケースが多く報告されています。設定ミスは外見上は動いているように見えるため、テストで見落としやすい点も危険なポイントです。
CORSの仕組みと設定ミスのパターン
CORSの基本的な流れ
ブラウザとサーバーのやり取りでは、サーバーが**Access-Control-Allow-Origin**というHTTPヘッダーで「どのドメインからのアクセスを許可するか」を返します。
| ヘッダー名 | 役割 | 安全な設定例 |
|---|---|---|
Access-Control-Allow-Origin | 許可するオリジン（ドメイン）を指定 | https://example.com |
Access-Control-Allow-Credentials | Cookieなど認証情報の送信を許可するか | false（原則） |
Access-Control-Allow-Methods | 許可するHTTPメソッドを指定 | GET, POST |
Access-Control-Allow-Headers | 許可するリクエストヘッダーを指定 | Content-Type |
代表的な設定ミスのパターン
【パターン1】ワイルドカード設定
Access-Control-Allow-Origin: *
→ すべてのドメインからのアクセスを許可（認証情報がない場合でも情報漏えいリスク）
【パターン2】リクエスト元をそのまま反映（最も危険）
リクエスト: Origin: https://evil-site.com
レスポンス: Access-Control-Allow-Origin: https://evil-site.com ← 攻撃者のサイトを許可！
Access-Control-Allow-Credentials: true ← Cookieまで渡す！
【パターン3】サブドメインの前方一致チェックミス
許可したいドメイン: https://myapp.example.com
ミスった正規表現: example.com で終われば全部OK
攻撃者が用意: https://evil-example.com → 通過してしまう攻撃が成立する流れ
攻撃者が https://evil-site.com を用意し、被害者がそこにアクセスすると、ブラウザが裏側で正規のAPIサーバーにリクエストを送り、被害者のCookieを使ってデータを取得。結果を攻撃者のサーバーへ転送します。
歴史と背景
- 1995年頃 — ブラウザにJavaScriptが導入され始め、悪意あるスクリプトによる他サイトへのアクセスが問題視される
- 2006年頃 — W3CがCORSの仕様策定を開始。「制限を壊すのではなく、安全に緩める」アプローチが採用される
- 2014年 — CORS仕様がRFC 6454（オリジンの概念）およびW3C勧告として正式化
- 2018年頃〜 — SPA（シングルページアプリケーション）やREST APIの普及で、フロントエンドとバックエンドが別ドメインになる構成が急増。CORS設定の機会が激増し、ミスも増加
- 2019年 — PortSwigger（BurpSuite開発元）の調査で、主要Webサービスの約200サイトに深刻なCORS設定ミスが存在すると報告。設定ミスが「よくある脆弱性」として広く認識される
- 現在 — OWASPのAPI Security Top 10にも関連項目として掲載。クラウドネイティブ・マイクロサービス時代においてますます重要な設定項目に
正しい設定 vs 設定ミス の比較
発注・選定時のチェックポイント
| チェック項目 | 確認内容 | 対応 |
|---|---|---|
| CORS設定の管理 | 許可オリジンは固定リストで管理されているか | 仕様書・設計書に明記させる |
*の使用禁止 | 認証付きAPIにワイルドカードを使っていないか | セキュリティ要件として明文化 |
| Credentialsの扱い | Allow-Credentials: trueとの組み合わせに注意 | レビュー・監査の対象に含める |
| セキュリティテスト | CORS設定のペネトレーションテストを実施しているか | 受け入れ検査に含める |
関連する規格・RFC
| 規格・RFC番号 | 内容 |
|---|---|
| RFC 6454 | オリジン（Origin）の概念を定義したRFC |
| W3C CORS勧告（2014） | CORSの正式仕様。Access-Control-*ヘッダーを定義 |
| OWASP API Security Top 10 | API3（過剰なデータ露出）や不適切な設定としてCORSミスが言及される |
| Fetch Living Standard | 現在のブラウザにおけるCORSの実装仕様（WHATWGが管理） |
関連用語
- Same-Origin Policy — ブラウザに組み込まれた「異なるドメインへの通信を原則禁止する」セキュリティの基本ルール
- CSRF（クロスサイトリクエストフォージェリ） — ユーザーが意図しないリクエストを別サイトから送らせる攻撃。CORSと混同されやすい
- XSS（クロスサイトスクリプティング） — Webページに悪意あるスクリプトを埋め込む攻撃。CORS設定ミスと組み合わせると被害が拡大する
- プリフライトリクエスト — ブラウザがCORSの本番リクエスト前に送る「事前確認」のHTTPリクエスト（OPTIONSメソッド）
- REST API — CORS設定ミスが頻繁に発生するAPIの代表的な設計スタイル
- ペネトレーションテスト — CORS設定ミスを発注前・本番前に発見するためのセキュリティ検査手法