CORSプリフライトの深淵：ブラウザとサーバーが織りなす「見えない交渉」の最適化
インフラアーキテクトとして現場に立つと、たかがCORS、されどCORSという言葉を痛感する場面に何度も遭遇する。開発環境では動いていたはずのAPIが、本番環境の厳格なセキュリティポリシー下で突如として「403 Forbidden」や「CORS error」を吐き出す。この時、多くのエンジニアはブラウザのデベロッパーツールを眺めて呆然とするが、真のプロフェッショナルはパケットの中に潜む「OPTIONSメソッド」という名の交渉プロトコルを読み解く。
今日は、APIのセキュリティとパフォーマンスの境界線に位置するCORSプリフライトリクエストの深淵を覗いてみよう。
1. プリフライトリクエストの正体：なぜ「無駄な」通信が必要なのか
ブラウザがGETやPOSTを送る前に送出するOPTIONSリクエスト。これを「無駄なオーバーヘッド」と切り捨てるのは早計だ。これは、ブラウザという「ユーザーの端末で動くサンドボックス」が、悪意あるスクリプトからサーバーを守るための、極めてプリミティブかつ重要な検問所である。
通信シーケンスを俯瞰すると、以下のようになる。
1. SYN/ACKの完了: TCP 3-way handshakeが完了し、TLSハンドシェイクで暗号化パイプが開かれる。
2. OPTIONSメソッドの送出: ブラウザが「このオリジンから、このヘッダーを使ってリクエストしても良いか？」とサーバーに打診する。
3. サーバーの応答: Access-Control-Allow-OriginやAccess-Control-Allow-Methodsを返し、許可を出す。
4. 本番リクエスト: ようやく目的のPOSTやPUTが飛ぶ。
ここで重要なのは、「この交渉にかかるRTT（Round Trip Time）が、ユーザー体験に直結する」という点だ。
2. ネットワーク層からの最適化：RTTとTLSハンドシェイクの軽減
プリフライトリクエストは往復の通信を伴うため、遅延耐性の低いネットワーク環境では致命的となる。これを防ぐためのインフラ的アプローチはいくつか存在する。
TLS Session Resumptionの徹底
CORSのプリフライトと本番リクエストが別々のTCP接続で行われるようでは、プロトコルスタックの設計として失格だ。Keep-Aliveを有効にし、TLS 1.3の0-RTT（注意深く運用する必要があるが）を活用することで、ハンドシェイクのコストを極限まで圧縮する。
Access-Control-Max-Ageの賢明な設定
HTTPヘッダーのAccess-Control-Max-Ageは、プリフライトの結果をブラウザにキャッシュさせる期間を指定するものだ。これを過小評価してはいけない。
# Nginxでの設定例
# プリフライトの結果を24時間（86400秒）キャッシュさせる
# これにより、頻繁なアクセスにおける無駄なOPTIONSリクエストを抑制する
location /api/ {
add_header 'Access-Control-Allow-Origin' 'https://myapp.com';
add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS';
add_header 'Access-Control-Allow-Headers' 'Authorization, Content-Type';
add_header 'Access-Control-Max-Age' 86400; # 86400秒 = 24時間
if ($request_method = 'OPTIONS') {
return 204; # 204 No Contentで即座に応答を返す
}
}3. セキュリティとパフォーマンスのトレードオフ
Access-Control-Allow-Originにワイルドカード（*）を指定するのは、認証が必要なAPIにおいてはNGであることは周知の事実だが、一方で「Allowed Origin」をホワイトリスト化する際に、正規表現や動的生成を行うと、サーバー側のロジック負荷がわずかに増大する。
大規模トラフィックを捌くアーキテクトとしては、このロジックをアプリケーション層ではなく、Edge（CDNやリバースプロキシ）で処理することを強く推奨する。
脆弱性の回避：ヘッダーの注入と検証
多くのセキュリティ事故は、Access-Control-Allow-Originヘッダーを「リクエストのOriginヘッダーをそのまま反射させる」という安易な実装によって引き起こされる。これはXSSの踏み台となり、クロスサイトでのデータ搾取を許す。
必ずサーバー側で許可されたリスト（Allowed-Origins-Set）とのマッチングを行い、ブラックリストではなくホワイトリスト方式で制御すること。
4. プロトコルスタックのチューニング：パケットレベルの視点
プリフライトリクエストが頻発するような高負荷環境では、LinuxカーネルのTCPスタックも重要になる。
- TCP Fast Open (TFO): クライアントとサーバーが過去に通信した実績があれば、ハンドシェイクの最初のパケットでデータ（OPTIONSリクエスト）を運ぶことが可能になる。
- BBR (Bottleneck Bandwidth and RTT): 輻輳制御アルゴリズムを
BBRに設定し、パケットロス発生時のスループット低下を最小限に抑える。
# LinuxカーネルのTCP設定例（sysctl.conf）
# TCP Fast Openを有効化
net.ipv4.tcp_fastopen = 3
# キューのサイズを大きくし、プリフライトのバーストに備える
net.core.somaxconn = 65535結び：ネットワークは嘘をつかない
CORSのプリフライトは、単なるWebの制約ではなく、ネットワークという不安定な世界で「安全にデータをやり取りするための合意形成」である。
「なぜ動かないのか」と悩んだ時、パケットキャプチャをとり、TCPのシーケンス番号とHTTPヘッダーのやり取りを追ってみてほしい。そこには、教科書には書かれていない、サーバーとブラウザの泥臭くも美しい対話があるはずだ。
パフォーマンスとセキュリティは相反するものではない。適切なプロトコル理解と、インフラレベルでのチューニングによって、両立させることが我々アーキテクトの使命である。次回のAPI設計時には、ぜひ「OPTIONSメソッドがどう旅をしているか」を想像しながら、ヘッダーを記述してほしい。
コメント