カスタムヘッダーによるCSRF防御の「幻想」と、CORSプリフライトの深淵
多くのエンジニアが「X-Requested-WithヘッダーさえチェックしていればCSRFは防げる」と信じ込んでいる。これは半分正解であり、同時に、現代のブラウザ仕様と攻撃者の執念を過小評価した致命的な誤解でもある。
今日は、表層的なセキュリティガイドラインを捨て、プロトコルレベルの挙動からこの手法の限界と、真に堅牢なアーキテクチャについて語ろう。
—
1. 「X-Requested-With」という名の不完全な盾
X-Requested-With: XMLHttpRequest のようなカスタムヘッダーを検証する手法は、歴史的に「Same-Origin Policy (SOP) により、他ドメインのスクリプトはカスタムヘッダーを付与したリクエストを送信できない」という仕様を根拠にしている。
確かに、単純なHTMLフォームや、単純リクエスト（Simple Requests）の範囲内であれば、カスタムヘッダーの付与はブラウザによって禁止される。しかし、ここには二つの大きな盲点がある。
- FlashやJavaアプレットの亡霊（レガシーの呪縛）: 現代ではほぼ死滅したが、古いブラウザプラグインはSOPをバイパスしてカスタムヘッダーを送出できた。これらが残るエンタープライズ環境では、この防御は無力だ。
- CORSプリフライトの誤解: 開発者が最も見落とすのは、「CORSのプリフライト（OPTIONSメソッド）が成功してしまえば、カスタムヘッダーは容易に送信可能になる」という事実である。
2. CORSプリフライトを悪用した防御回避のメカニズム
攻撃者は、ターゲットのAPIサーバーが Access-Control-Allow-Origin を緩く設定している（あるいは反射的に設定している）ことを見抜くと、以下のような攻撃パスを描く。
1. プリフライトの通過: ブラウザは OPTIONS リクエストを発行する。サーバー側で Access-Control-Allow-Origin: や、不適切な正規表現によるオリジン許可がなされていれば、プリフライトは「合格」する。
2. ヘッダーの注入: プリフライトが通過すれば、ブラウザは「このオリジンはカスタムヘッダーを付与する権限がある」と判断し、攻撃者のJavaScriptコードから送信される X-Requested-With: XMLHttpRequest を正当なものとして送信する。
つまり、「CORSの設定が甘い環境」において、カスタムヘッダーによる防御は単なる「気休め」に過ぎない。
3. 実践：セキュアな防御アーキテクチャの構築
CSRF対策において、カスタムヘッダーは「補助」であって「主軸」ではない。我々が求めるべきは、攻撃者が決して模倣できない「不可視のトークン」である。
推奨される防御層の設計
現代のWebアプリケーションでは、以下の多層防御を推奨する。
1. Strict SameSite Cookie: まずはここから。Set-Cookie: __Host-session=...; SameSite=Strict; Secure; Path=/ を徹底する。
2. Custom Request Header (検証用): 依然として有効だが、CORSと組み合わせて使うこと。
3. Anti-CSRF Token (Double Submit Cookieの限界を理解する): ステートフルなセッション管理が基本だが、API指向の設計であれば、以下のような実装を検討せよ。
// フロントエンド: サーバーから取得した値をヘッダーにセット
// 重要なのは、このトークンが「Cookieには保存されず、メモリ上のみに存在すること」
const csrfToken = fetch(‘/api/csrf-token’).then(res => res.json());
axios.post(‘/api/update’, data, {
headers: {
‘X-CSRF-TOKEN’: csrfToken, // ここでカスタムヘッダーを付与
‘X-Requested-With’: ‘XMLHttpRequest’ // 二重のチェックとして機能
}
});
// バックエンド (Go言語の例): ミドルウェアでの厳格な検証
func CSRFMiddleware(next http.Handler) http.Handler {
return http.HandlerFunc(func(w http.ResponseWriter, r http.Request) {
// 1. オリジン検証 (必須)
origin := r.Header.Get(“Origin”)
if !isAllowed(origin) {
http.Error(w, “Forbidden”, http.StatusForbidden)
return
}
// 2. カスタムヘッダーとトークンの突き合わせ
// Double Submit Cookieを疑うのではなく、Server-Side Sessionとの照合を推奨
if r.Header.Get(“X-CSRF-TOKEN”) != getSessionToken(r) {
http.Error(w, “Invalid CSRF Token”, http.StatusForbidden)
return
}
next.ServeHTTP(w, r)
})
}
4. 結びに：ガードレイルとしてのセキュリティ
生成AIが台頭する現在、プロンプトインジェクションへの対策も同様だが、セキュリティの本質は「境界線（Boundary）をどこに引くか」にある。カスタムヘッダーは、HTTPというプロトコルの境界線において、認証済みのリクエストかどうかを識別する一つのサインに過ぎない。
「CORSは信頼の境界線ではない」。このことを肝に銘じてほしい。
もし君がチーフアーキテクトなら、開発チームに対し「CORS設定のブラックリスト管理」を許可するのではなく、「SameSite=Strictとセッションベースのトークン認証」という、プロトコルの仕様に依存した堅牢なガードレイルを強制すべきだ。
泥臭いパケット解析や、ブラウザの仕様変更（Privacy Sandbox等）を常に注視し、教科書を疑うこと。それこそが、我々エンジニアが備えるべき唯一の防御力である。
コメント