はじめに：なぜ、そのAPIは「意図しないリクエスト」に怯えなければならないのか
こんにちは。インフラとプロトコルの深淵を愛するシニアエンジニアの私だ。
日々、設計書やAPI仕様書をレビューしていると、「美しいREST APIのURL設計」や「適切なHTTPステータスコードの選択」には熱心なのに、セキュリティの境界線、特にブラウザという名の「気まぐれで危険なクライアント」が絡む防御機構になると、途端に解像度が落ちる現場に遭遇する。
Web API設計において、しばしば議論になるのが CSRF（Cross-Site Request Forgery：クロスサイトリクエストフォージェリ） 対策だ。
「ウチのAPIはSPA（Single Page Application）からしか叩かれないから大丈夫」「トークン認証（Bearer認証）だからCookieは使っていない」——そう言って油断しているそこのあなた。その油断が、深夜の緊急アラートを呼び寄せるフラグになる。
今回は、数々の修羅場をくぐり抜けてきた私が、ブラウザの標準機能を逆手に取った実戦的なCSRF防御策、「カスタムヘッダー（例: X-Requested-With など）を必須化するアプローチ」 について、プロトコルの挙動とコードレベルの実装まで徹底的に解説しよう。教科書には載っていない、現場の泥臭い知見と共にお届けする。
—
1. CORSの裏をかく悪夢：CSRFのメカニズムと限界
そもそも、なぜAPIにCSRF対策が必要なのか。
現代のWebアプリケーションの多くは、セッション管理にCookie（特に SameSite 属性が適切に設定されていない場合や、古いブラウザ環境）や、ローカルストレージ（これは別種のXSSリスクがあるが本筋ではないので置いておく）、あるいはAuthorizationヘッダーを利用している。
しかし、攻撃者が用意した悪意ある外部サイト（evil.com）から、ユーザーのブラウザを介してターゲットのAPIサーバー（api.yourcompany.com）へリクエストを強制送信させられたらどうなるか。
ここで重要なのは、「ブラウザは、同一オリジンポリシー（Same-Origin Policy: SOP）を適用しつつも、Cookieなどの資格情報を特定のクロスオリジンリクエストに自動付与する」 という仕様の存在だ。
1. 被害者が evil.com にアクセスする。
2. evil.com のJavaScriptやフォームが、裏で https://api.yourcompany.com/v1/user/update に対して、ステート変更を伴う POST リクエストを飛ばす。
3. ブラウザは、被害者が api.yourcompany.com に対して持っているセッションCookieを勝手にリクエストヘッダーに付与して送信してしまう。
4. サーバー側は、正規のセッションCookieを持ったリクエストであるため、それを信じてユーザーのデータを書き換えてしまう。
CORS（Cross-Origin Resource Sharing）があるから大丈夫、ではない理由
「CORSがあるから、別ドメインからのレスポンスはJavaScriptで読めないはずだ」と思うかもしれない。その通り、SOPやCORSは「レスポンスの読み取り」を防ぐものであって、「リクエストの送信（書き込み）」そのものをブロックするわけではない。
HTMLの <form> タグによる POST 送信や、一部の単純なリクエストは、CORSの事前リクエスト（Preflight Request）を発生させずにサーバーへ到達してしまう。サーバー側が状態を更新する処理（State-changing requests）を POST や PUT、DELETE で受けている場合、CSRFの格好の標的となるのだ。
—
2. カスタムヘッダーによる防御の原理
そこで登場するのが、「カスタムヘッダーの強制」 という非常にシンプルかつ強力なインフラ・アプリケーション層の防衛策である。
代表的なものが X-Requested-With: XMLHttpRequest というヘッダーだ。元々はAjaxリクエスト（jQueryなど）を識別するために広く使われてきた非公式の歴史を持つが、現代のセキュリティ文脈では「CSRFキラー」として機能する。
なぜカスタムヘッダーでCSRFを防げるのか？
ブラウザの標準機能（HTMLの <form> タグや通常のリンクなど）を使って、任意のカスタムHTTPヘッダー（例: X-Requested-With や X-Custom-CSRF-Protection）を付与したリクエストをクロスオリジンで送信することは、ブラウザの仕様上、原則として不可能である。
もし、外部サイト（evil.com）からJavaScript（Fetch APIなど）を使ってカスタムヘッダー付きのリクエストを無理やり送ろうとするとどうなるか？
ブラウザはCORSの厳格なルールに基づき、実際のデータ送信の前に必ず Preflightリクエスト（OPTIONS メソッド） をサーバーに飛ばす。
1. ブラウザは OPTIONS /v1/user/update を送信し、「このカスタムヘッダーを含んだリクエストを送ってもいいですか？」とサーバーに伺いを立てる。
2. サーバー側がCORS設定（Access-Control-Allow-Headers）でそのカスタムヘッダーの許可を返していなければ、ブラウザは本番のリクエストの送信を即座にブロックする。
3. 仮にサーバーが evil.com からのCORSを許可していた（Access-Control-Allow-Origin: * や不適切な設定）としたら話は別だが、適切に管理されたAPIであれば、そもそも信頼できるオリジン（自社フロントエンドのドメイン等）以外からのPreflightを拒否する。
つまり、「APIエンドポイントにおいて、特定のカスタムヘッダーの存在を必須条件（Mandatory）とし、かつそのヘッダーがHTMLの標準フォームや単純なクロスオリジンリクエストでは付与できない」 という状況を作ることで、CSRFの自動送信を根絶やしにできるのだ。
—
3. 通信フロー（シーケンス）の全貌
実際のブラウザとAPIサーバー間の通信がどのように行われるのか、プリフライトを伴うFetch APIのシーケンスを見てみよう。
[Browser (SPA Client)] [API Server (With Custom Header Guard)]
| |
| --- (1) Preflight: OPTIONS /v1/resource --->|
| (Access-Control-Request-Headers: |
| X-Requested-With) |
| |
| <--- (2) 200 OK / CORS Allowed -------------|
| (Access-Control-Allow-Headers: |
| X-Requested-With) |
| |
| --- (3) Actual Request: POST /v1/resource ->|
| (X-Requested-With: XMLHttpRequest) |
| (Cookie / Authorization Header) |
| |
| <--- (4) 200 OK (Data Processed) -----------|
| |もし、悪意ある外部サイト（evil.com）がこのAPIを攻撃しようとしても、ブラウザが勝手に X-Requested-With ヘッダーを付与したHTMLフォームを作成することは不可能であり、JSから無理に送ろうとすればCORSのプレフライトで弾かれるか、サーバー側でカスタムヘッダーの欠落により 400 Bad Request や 403 Forbidden として即座に弾かれることになる。
—
4. 実装・設定サンプル：現場でどう書くか・どう守るか
ここからは、具体的なコードとインフラ設定のサンプルを提示しよう。実務でそのままコピー＆ペーストして微調整できるようにしている。
4.1. バックエンド側（Python / FastAPI の例）
APIサーバー側で、リクエストヘッダーに特定のカスタムヘッダーが存在するかを検証するミドルウェア、あるいは依存性注入（Dependency）の例だ。
from fastapi import FastAPI, Header, HTTPException, status
app = FastAPI()
async def verify_custom_header(x_requested_with: str = Header(None)):
"""
カスタムヘッダーの存在と値を検証する依存関数
実務では X-Requested-With や独自定義の X-CSRF-Protect ヘッダーを見る
"""
if x_requested_with != "XMLHttpRequest":
raise HTTPException(
status_code=status.HTTP_403_FORBIDDEN,
detail="Forbidden: Missing or invalid required custom header."
)
@app.post("/api/v1/settings")
async def update_settings(x_requested_with: str = Header(None)):
# 依存関数をルートに適用、またはミドルウェアで一括検証する
await verify_custom_header(x_requested_with)
# 実際のビジネスロジック（設定の更新）
return {"status": "success", "message": "Settings updated securely."}4.2. フロントエンド側（JavaScript / Fetch API の例）
SPAなどのフロントエンドからAPIを叩く際は、必ず共通のHTTPクライアント（AxiosやFetchのラッパー）でカスタムヘッダーを付与するように設計する。
/**
* 共通APIクライアントのラッパー関数
* すべてのリクエストに自動的にカスタムヘッダーを付与する
*/
async function secureApiRequest(endpoint, options = {}) {
const defaultHeaders = {
'Content-Type': 'application/json',
// CSRF対策としてのカスタムヘッダーを強制付与
'X-Requested-With': 'XMLHttpRequest'
};
const config = {
...options,
headers: {
...defaultHeaders,
...(options.headers || {})
},
// クッキーを送信する場合は credentials を設定
credentials: 'include'
};
const response = await fetch(endpoint, config);
if (!response.ok) {
throw new Error(`API Error: ${response.status} ${response.statusText}`);
}
return await response.json();
}
// 実際の使用例
async function updateUserProfile(newBio) {
try {
const result = await secureApiRequest('/api/v1/settings', {
method: 'POST',
body: JSON.stringify({ bio: newBio })
});
console.log('Update success:', result);
} catch (error) {
console.error('Update failed:', error);
}
}4.3. 動作検証用（curl コマンド）
インフラエンジニアやQA担当者が、正しくカスタムヘッダー検証が機能しているかを検証するための curl コマンドだ。
# 【正常系】カスタムヘッダーが付与されているため、リクエストが通るべきケース
curl -X POST "https://api.yourcompany.com/api/v1/settings" \
-H "Content-Type: application/json" \
-H "X-Requested-With: XMLHttpRequest" \
-d '{"bio": "Hello Protocol"}'
# 【異常系】カスタムヘッダーが欠落しているため、403 Forbidden が返るべきケース
curl -X POST "https://api.yourcompany.com/api/v1/settings" \
-H "Content-Type: application/json" \
-d '{"bio": "Attack Payload"}'—
5. 現場のシニアが教える「陥りがちな罠」と実務的Tips
このカスタムヘッダー方式は非常に効果的だが、いくつかの「落とし穴」が存在する。現場で血を流さないために、以下のTipsを頭に叩き込んでおいてほしい。
1. X-Requested-With は「標準仕様」ではない
歴史的経緯から、X-Requested-With はW3Cなどの公式なRFC標準として策定されたものではない（De facto標準）。そのため、将来的なブラウザの仕様変更や、特殊なHTTPクライアント、あるいは悪意ある攻撃者が何らかの脆弱性を突いてカスタムヘッダーを偽装できる可能性が「理論上」ゼロとは言い切れない（実際にはCORSの壁があるため困難だが）。
対策: これ単体に過信せず、厳格な SameSite=Strict もしくは Lax のCookie設計や、いわゆる Synchronizer Token Pattern（CSRFトークン）との多層防御（Defense in Depth）として組み合わせるのがプロの作法だ。
2. CORSの Access-Control-Allow-Headers 設定ミス
APIサーバー側のリバースプロキシ（NginxやAPI Gateway）やフレームワークで、CORSヘッダーの設定を適当に済ませていると、予期せぬトラブルに見舞われる。
もしフロントエンドから X-Requested-With を送っているのに、サーバーがそれを許可していなければ、前述の通りPreflight（OPTIONS）でブロックされ、正規のユーザーすらAPIにアクセスできなくなる（いわゆる「CORS地獄」の完成だ）。
Nginxなどで設定する場合は、以下のように許可するヘッダーを明示すること。
# NginxでのCORS設定例
add_header 'Access-Control-Allow-Origin' 'https://app.yourcompany.com' always;
add_header 'Access-Control-Allow-Methods' 'GET, POST, PUT, DELETE, OPTIONS' always;
add_header 'Access-Control-Allow-Headers' 'Content-Type, X-Requested-With, Authorization' always;
add_header 'Access-Control-Allow-Credentials' 'true' always;3. GETリクエストへの過信
大前提として、データ状態を変更する操作（State-changing: POST, PUT, PATCH, DELETE）にのみこの対策を厳格に適用すればよい。GET リクエストは、HTTP仕様書（RFC 7231など）において「セーフメソッド（副作用を持たない）」と定義されているため、CSRFのターゲットになるべきではない。もし GET でデータを書き換えるような設計にしているなら、即座にそのアーキテクチャを見直すべきだ。
—
おわりに：プロトコルとブラウザの挙動を愛せよ
セキュリティの強度は、一番弱い鎖の強度に依存する。どれだけ堅牢なデータベースを構築し、どれだけ美しいAPIのURL設計をしても、ブラウザという「エンドユーザーのデバイス上で勝手に動くブラックボックス」の挙動を理解していなければ、一瞬でシステムは崩壊する。
カスタムヘッダーを用いたCSRF対策は、複雑なセッション管理の仕組みを導入する前に、HTTPのヘッダーという原始的かつ強力なシグナルを利用してシステムを守る、非常にエレガントな手法だ。
「なぜこのヘッダーが必要なのか」「ブラウザは裏でどのようなプレフライトを飛ばしているのか」。
その裏側のパケットの息吹を感じ取れるようになったとき、あなたも真のネットワークプロトコルスペシャリスト、そして信頼されるインフラアーキテクトへの階段を一歩登っているはずだ。
さあ、今すぐ自身のプロダクトのAPI仕様書を開き、すべての状態変更系エンドポイントに「そのヘッダー、本当に必須になっていますか？」と問いかけてみよう。
コメント