【テクニカル・上級編】 CSRF(Cross-Site Request Forgery)対策としてのカスタムヘッダー – Web APIアーキテクチャ・データ連携実践ガイド

REST APIの深淵：カスタムヘッダーによるCSRF防御と、その裏にあるネットワークの「流儀」

インフラアーキテクトとして、これまで数多のAPI設計を見てきたが、未だに「CSRF対策はどうすればいいか？」という議論が繰り返されるのを目にする。Cookieベースの認証を使っている以上、ブラウザの自動送信という「便利すぎる機能」が牙を剥くのは避けられない。

多くのエンジニアが「まあ、X-Requested-Withでもつけておけば大丈夫でしょう」と安易に結論づけるが、我々インフラスペシャリストは、その裏で何が起きているのか、そしてそれがネットワークのパフォーマンスにどう影響するのかを理解しておく必要がある。

今日は、カスタムヘッダーという「論理的な壁」が、いかにしてブラウザの挙動を制御し、かつネットワークのオーバーヘッドを最小化すべきかというテーマで、深淵を覗いていく。

—

なぜカスタムヘッダーが「防御」になるのか

CSRFの根本的な原因は、ブラウザが勝手にクッキーを付与してリクエストを送ってしまう点にある。だが、XMLHttpRequestやFetch API経由でカスタムヘッダー（例: X-Requested-With: XMLHttpRequest や X-CSRF-TOKEN）を付与しようとすると、ブラウザは「プリフライトリクエスト（OPTIONSメソッド）」を飛ばさざるを得なくなる。

ここで重要なのは、「CORS（Cross-Origin Resource Sharing）の仕組み」だ。

カスタムヘッダーが付与されたリクエストは「シンプルリクエスト」の条件から外れる。結果、ブラウザはサーバーに対して「このドメインからこのヘッダーをつけてリクエストして良いか？」という確認（OPTIONS）を強制される。ここでサーバーが Access-Control-Allow-Headers で許可を出さなければ、実際のリクエストは送信されない。つまり、攻撃者のスクリプトがどれだけ巧みにリクエストを捏造しても、カスタムヘッダーの壁を突破できなければ、パケットがサーバーのアプリケーション層に到達することはないのだ。

—

ネットワークの「流儀」：パフォーマンスを犠牲にしないために

セキュリティのためにプリフライト（OPTIONS）が増えるのは、ネットワークの観点からはRTT（Round Trip Time）の増加を意味する。これを無視して設計すると、APIのレスポンスタイムは確実に悪化する。

1. TCPハンドシェイクとTLSセッションの最適化

もしOPTIONSリクエストのたびにフルハンドシェイクを行っていれば、パフォーマンスは壊滅的だ。ここでは HTTP/2 または HTTP/3 の採用が前提となる。接続を永続化（Keep-Alive）し、TLS 1.3の 0-RTT（TLS False Startの進化版）を活用して、ハンドシェイクの往復回数を極限まで減らす。

2. HPACK/QPACKヘッダー圧縮の恩恵

「カスタムヘッダーを毎回つけるのは、パケットサイズが肥大化して無駄ではないか？」という懸念は、HTTP/2 以降のヘッダー圧縮を知っていれば解消される。
HPACKは、頻出するヘッダーをインデックス化し、動的テーブルを用いて圧縮する。カスタムヘッダーは一度送信されれば、以降は小さなインデックス値に置換されるため、ネットワーク帯域を圧迫する心配はほとんどない。

—

実装におけるベストプラクティス

防御層は「二重」にするのが鉄則だ。ヘッダー検証に加え、CSRFトークンのバリデーションを組み合わせるのが、現代のAPI設計における正解である。

Nginxでカスタムヘッダーを強制検証する例を挙げよう。

# Nginx側の設定例
location /api/ {
    # プリフライトリクエストの許容とキャッシュ
    if ($request_method = 'OPTIONS') {
        add_header 'Access-Control-Allow-Origin' 'https://your-app.com';
        add_header 'Access-Control-Allow-Headers' 'X-Requested-With, Content-Type, X-CSRF-TOKEN';
        add_header 'Access-Control-Max-Age' 86400; # プリフライトを24時間キャッシュ
        return 204;
    }

    # カスタムヘッダーが存在しない場合は拒否
    if ($http_x_requested_with = "") {
        return 403;
    }

    # ここにバックエンド（Node.js/Go/PHP等）へのプロキシ設定
    proxy_pass http://backend_upstream;
}

パフォーマンスチューニングの現場視点

Access-Control-Max-Age: この値を適切に設定することで、ブラウザ側のプリフライトをキャッシュさせる。これにより、連続するリクエストでのRTTを削減できる。
TCPバッファ: 大規模なAPI通信を行う場合は、Linuxカーネルの sysctl 設定で net.ipv4.tcp_rmem や net.ipv4.tcp_wmem を適切にチューニングし、高トラフィック時でもパケットロスを抑える必要がある。

—

結論：技術は「バランス」の上に成り立つ

カスタムヘッダーによるCSRF対策は、ブラウザのセキュリティモデルを逆手に取った非常にエレガントな手法だ。しかし、それは「ヘッダーを付与すれば終わり」という単純な話ではない。

プリフライトのオーバーヘッドをどう隠蔽するか（HTTP/2, Keep-Alive, キャッシュ）
ヘッダー圧縮を意識した設計になっているか（HPACKの理解）
セキュリティとネットワークの遅延のトレードオフをどこで取るか

これら全てを俯瞰して設計できるのが、真のインフラアーキテクトだ。ただAPIを叩くだけのコードを書くのではなく、パケットがネットワークカードを通過し、カーネルのスタックを駆け上がり、アプリケーションに届くまでの全てのステップを想像してほしい。

プロトコルは嘘をつかない。君が設計したアーキテクチャの質は、パケットの挙動に全て現れるのだから。