カスタムHTTPヘッダーによるCSRF防御は「最後の砦」ではない。実務で陥る罠と、その先の正攻法
「X-Requested-Withヘッダーさえチェックしていれば、CSRFは防げる」。もし君がそう教わったのなら、それは半分正解で、半分は致命的な死神の入り口だ。
現場で数多のインシデントを見てきたが、この「独自ヘッダー検証」という手法は、確かにAjax全盛期のアプリでは一定の抑止力になる。だが、ブラウザの仕様変更やCORSの進化によって、その「壁」は想像以上に脆くなっている。今回は、なぜこの手法が完全な防御にはなり得ないのか、そして我々が実装すべき本当の防衛線について、泥臭い現実を交えて解説しよう。
—
1. なぜ「カスタムヘッダー」は突破されるのか
X-Requested-WithやX-CSRF-Tokenのようなカスタムヘッダーを検証する手法は、「ブラウザの同一生成元ポリシー（Same-Origin Policy: SOP）」に依存している。
正常なAjaxリクエストならブラウザが自動的にヘッダーを付与してくれるが、攻撃者が別のドメインから仕掛けるリクエストには、通常そのヘッダーを強制的に含めることはできない。これが理論上の「守り」だ。
しかし、現実は甘くない。以下のケースを想像してほしい。
脆弱なCORS設定という「抜け穴」
もし君が、APIサーバーでAccess-Control-Allow-Origin: を設定していたらどうなるか。あるいは、正規のドメインを指定していても、設定ミスや将来的なサブドメインの乗っ取りによって、攻撃者が正規のオリジンになりすませる状況が発生した場合、プリフライトリクエスト（OPTIONSメソッド）さえ突破すれば、攻撃者は好きなカスタムヘッダーを付与してリクエストを投げられる。
ブラウザは、「このドメインならカスタムヘッダーを許可していいよ」というサーバーからの許可（CORSポリシー）を受け取れば、いとも簡単に攻撃者のスクリプトに「カスタムヘッダーを付与する権限」を与えてしまうのだ。
—
2. 【実務レベル】防御の正攻法：Double Submit Cookie と SameSite 属性
カスタムヘッダーだけに依存するのは、鍵のかかっていない窓を段ボールで塞いでいるようなものだ。現代のWeb開発において、CSRF対策の黄金律は以下の2点に集約される。
1. SameSite Cookie属性（Strict または Lax）を全Cookieに適用する
2. Anti-CSRFトークンの実装（Double Submit Cookie法）
これらを組み合わせることで、万が一CORS設定が緩んでも、ブラウザ側とサーバー側の両面で攻撃を無効化できる。
実装サンプル：Python (Flask) での安全な構成
「カスタムヘッダーがあるからOK」ではなく、「トークンが一致しなければ問答無用で拒否」する実装が必須だ。
from flask import Flask, request, abort
import secrets
app = Flask(__name__)
CSRFトークンを生成してCookieにセットする例（サーバーサイドで管理）
def generate_csrf_token():
return secrets.token_hex(32)
@app.before_request
def csrf_protect():
# POST, PUT, DELETEメソッドのみ検証
if request.method in [“POST”, “PUT”, “DELETE”]:
token_from_header = request.headers.get(‘X-CSRF-TOKEN’)
token_from_cookie = request.cookies.get(‘csrf_token’)
# トークンが存在しない、または一致しない場合は即座に遮断
if not token_from_header or token_from_header != token_from_cookie:
abort(403, “CSRF検証に失敗しました”)
レスポンス時にSameSite属性を強制する設定
@app.after_request
def apply_caching(response):
response.set_cookie(
‘csrf_token’,
generate_csrf_token(),
samesite=’Lax’, # 最低でもLax、重要度が高いならStrict
secure=True, # HTTPS環境必須
httponly=False # JSから読み取る必要がある場合はFalse（ただしLaxで保護）
)
return response
—
3. インフラ側で叩き潰す：NginxによるWAF的防衛
コードレベルの対策は必須だが、もし君が大規模なトラフィックを捌くインフラエンジニアなら、ゲートウェイ側で「怪しいリクエスト」を間引く設定も検討すべきだ。
例えば、特定のヘッダーがないリクエストを不正とみなして弾くNginxの拒絶ルールは、多層防御として非常に有効だ。
Nginx設定例：X-CSRF-TOKENがないPOSTリクエストを拒否
map $request_method $is_csrf_protected {
POST 1;
PUT 1;
DELETE 1;
default 0;
}
server {
…
if ($is_csrf_protected = 1) {
# X-CSRF-TOKENヘッダーが存在しない場合は403を返す
if ($http_x_csrf_token = “”) {
return 403;
}
}
}
—
最後に：セキュリティは「積み上げ」である
今日伝えたかったのは、「カスタムヘッダーは決して無意味ではないが、それ一つで万能だと思い込むことが最大のリスクである」ということだ。
- ブラウザのSameSite属性（防御の核）
- Anti-CSRFトークン（攻撃者が推測不可能なランダム値）
- 厳格なCORSポリシー（最小権限の原則）
これらを適切に組み合わせて初めて、君のアプリケーションは強固な鎧を纏うことになる。
もし君が開発リーダーなら、まずはチームの全員に「自分のアプリが、どのブラウザのデフォルト挙動に守られているのか」を一度確認させてほしい。技術の背後にあるブラウザの仕様を理解した時、君たちの書くコードは「教科書通り」から「現場で戦える」ものへと進化するはずだ。
明日からのコードレビューで、この視点をぜひ活かしてくれ。健闘を祈る。
コメント