2026.05.01

【CORS・SOP編】ブラウザの境界線を突破する手口と守り方｜CTF思考フレームワーク #10

安全に生きたい編集部

📖 この記事はシリーズの一部です

「CTF思考フレームワーク」　認証・セッション編　#10 / 公開中 10記事　→　シリーズ一覧を見る →

CORS（Cross-Origin Resource Sharing）とSOP（Same-Origin Policy）は、ブラウザのセキュリティ境界の根幹。設定を1つ間違えると「他のサイトから自分のサイトのデータが読まれる」ということが起きます。今回はその境界線がどう崩れるかを見ていきましょう🚧

SOPの基本を押さえつつ、CORS設定ミス・クリックジャッキング・CSPの3点を整理していきます。

難易度：★★☆（中級）

このシリーズは「攻撃者の思考をなぞる」ことが目的。手を動かさなくても読み物として理解できるレベルです👍

CORSは「設定の油断」がそのまま脆弱性になる場所。地味だけど重要だよ🚧

この記事の難易度

難易度：★★☆（やさしめ）　／　所要：8〜10分　／　前提：CTF思考フレームワーク #09

Contents

👀 観察フェーズ：まず何を見る？
🤔 仮説フェーズ：攻撃者は何を考える？
🔬 検証フェーズ：どうやって確かめる？
⚔️ 攻撃フェーズ：実際の手口
🛡️ 防御フェーズ：どう守る？
🛡️ 今日からできる対策ツール
⚠️ よくある落とし穴
🧰 ツール早見表
🎓 本気で学びたい人へ
📚 もっと深く学びたい人へ
⚖️ 大事なお約束
📚 次に読みたい
🧪 自分で検証してみる

👀 観察フェーズ：まず何を見る？

まずOPTIONSプリフライトとAccess-Control-*系のレスポンスヘッダをじっくり観察！

Allow-Origin に Origin ヘッダをそのまま返す「動的エコー」＋ Allow-Credentials: true は、教科書的な脆弱パターン。要注意です。

DevToolsのNetworkタブで Access-Control-Allow-Origin がリクエスト元のOriginをエコーしていないか確認。Allow-Credentials: true との組み合わせは特に危険👀

Originをそのまま返してくる実装って、どんなサイトからでもアクセスOKって言ってるのと同じだよね…😱

🤔 仮説フェーズ：攻撃者は何を考える？

ブラウザ境界の崩し方は4つのパターンに分けられるよ。

ここから攻撃者の仮説を見ていきましょう。

🪞 仮説①：Originエコー＋Credentials許可

Access-Control-Allow-Originがリクエスト元のOriginをそのまま反射し、かつAllow-Credentials: trueだと、他サイトからCookie付きでAPI叩き放題。

🌐 仮説②：null Origin許可

Origin: nullを許可している実装は危険。サンドボックス化されたiframeやfile://から攻撃可能。

🖼️ 仮説③：X-Frame-Options欠落＝クリックジャッキング

X-Frame-Optionsもframe-ancestors(CSP)も無いと、透明iframeを被せて誤クリックを誘導するクリックジャッキングが成立。

🧨 仮説④：CSPのunsafe-inline

CSPにunsafe-inlineやunsafe-evalがあると、XSSの本来のブレーキが利かない。せっかくのCSPが台無しに。

「ブラウザが守ってくれる」と思いきや、設定次第で簡単に突破されてしまいます。CORSは「許可するときの作法」が大事です。

CORSもCSPも「設定したつもり」が一番危ないってことだね💧

🔬 検証フェーズ：どうやって確かめる？

検証は悪意あるOriginからfetchを投げて、レスポンスが返るかを見るのが手っ取り早いよ。

検証の流れ。

別ドメインのHTMLを立ててfetchして…レスポンスが読めたらアウトってことだね🧪

⚔️ 攻撃フェーズ：実際の手口

代表的な攻撃はこの3つ。

ここからは実戦シナリオを見ていきます。

① CORS設定ミスでデータ横抜き

悪意サイトから被害者のCookie付きでAPIを叩いてレスポンスを読み取る。CORS設定ミス1つで個人情報が抜ける。

② クリックジャッキングで意図せぬ操作

透明iframeで本物サイトを覆い、「ボタンを押させた」ことにして送金や削除を実行させる。

③ XSS × CSP回避

XSSが見つかった場合、CSPにunsafe-inlineがあればそのまま実行可能。CSPを設定していても無意味化されてしまいます。

CTF{cors_origin_must_be_explicit_allowlist}

CORSは「正しく開ける」のが大事。SOPは強力な防壁ですが、設定で穴を空けるのも開発者です。

🛡️ 防御フェーズ：どう守る？

ブラウザ境界を守る3点セットはこれ！🛡️

ブラウザ境界を正しく引く設計のポイントを見ていきます。

🔒 CORSはホワイトリスト＆Credentials厳格

Access-Control-Allow-Originは許可ドメインを明示的に列挙。ワイルドカード(*)とCredentialsの併用は禁止。

🖼️ X-Frame-Options + CSP frame-ancestors

X-Frame-Options: DENYまたはframe-ancestors 'self'でiframe埋め込みを禁止。クリックジャッキング根絶。

🧱 CSPはunsafe-inline禁止＋nonce運用

インラインスクリプトを許すなら必ずnonceかhashベースに。unsafe-inlineは本番ではゼロを目指す。

ブラウザに任せきりじゃなくて、サーバ側のヘッダで明確に境界を引くのが大事なんだね💡

🛡️ 今日からできる対策ツール

パスワードの使い回しや手動管理はどんなに気をつけても限界があります。🔑 パスワード管理ツール「ワンパス」なら、複雑なパスワードを安全に保管して「1つのマスターパスワード」だけ覚えられるので、今日から始める防御策としてしっくりきます。

※ 上記は他社サービスへのリンクです。購入は各自でご判断ください。

⚠️ よくある落とし穴

現場でよく見かけるミスはこんな感じです。

CORSで Allow-Origin: * と Allow-Credentials: true を併用しようとする（ブラウザがブロックするので機能しない＝設定意図のすれ違い）。
Origin ヘッダの値をそのままエコーして「動的に許可」する。
X-Frame-Options を忘れて、ログイン画面ごと iframe で奪われる。
CSPに unsafe-inline を残し、XSS発生時の防御層を失う。
サブドメインを Allow-Origin に含めて、サブドメインのXSSが本体まで波及。
開発環境のCORS緩設定を本番にそのまま反映してしまう。

🧰 ツール早見表

ここで使うツールを早見表にまとめました。

ツール	用途	ひと言
CSP Evaluator (Google)	CSPヘッダ評価	貼るだけで脆弱箇所を指摘
SecurityHeaders.com	セキュリティヘッダ採点	総合チェックの第一歩
Burp Suite	CORS / preflight検証	Origin改ざんも一発
CORS Misconfiguration Scanner	自動検査	CORtest など専用ツール