【入門編】CSRF攻撃におけるReferer/Originヘッダーの検証と注意点 – アプリケーションセキュリティ & 安全な開発防御ガイド

「家の中に泥棒を招き入れないために」CSRF対策とヘッダー検証のリアル

こんにちは！セキュリティの世界へようこそ。
日々、開発の現場でコードを書いていると、「セキュリティ対策って結局のところ何を守っているの？」と、ふと立ち止まることはありませんか？

今日は、Webセキュリティの登竜門とも言える「CSRF（クロスサイト・リクエスト・フォージェリ）」と、その対策の要である「Referer/Originヘッダーの検証」について、専門用語の壁を崩して、身近な防犯に例えてお話しします。

—

1. CSRF（クロスサイト・リクエスト・フォージェリ）って何者？

CSRFを一言で言うと、「あなたのふりをして、勝手に大事な手続きを済ませてしまう攻撃」です。

これを家の防犯に例えてみましょう。
あなたは今、自分の家の「合鍵（ログイン状態のクッキー）」を持っています。あなたはいつも通り、信頼できる銀行の窓口（Webサイト）に行って、「お金を振り込んでください」と頼みます。

ところが、攻撃者はあなたの知らないところで、「あなたを騙して、偽の窓口に連れて行き、そこで勝手に振り込みボタンを押させる」という罠を仕掛けます。銀行側から見れば、ちゃんと合鍵（クッキー）を持っているあなたが操作しているように見えるため、そのまま処理を通してしまうのです。これがCSRFの恐ろしさです。

—

2. 「どこから来たの？」を確認する防犯カメラ（Referer/Originヘッダー）

この攻撃を防ぐための第一歩が、「そもそも、このリクエストは本当にうちの銀行の入り口から来たものか？」を確認することです。

Webブラウザは、あるサイトから別のサイトへ移動したり、情報を送ったりするときに、「どこから来ましたか？」という履歴（RefererやOriginヘッダー）を自動的に添えてくれます。

Originヘッダー: 「このリクエストは https://my-bank.com から出たよ」という、より確実な出発地情報。
Refererヘッダー: 「直前には https://my-bank.com/transfer ページにいたよ」という、足跡情報。

サーバー側でこれらのヘッダーをチェックし、「うちのサイトのドメインから来ていないなら、怪しいから門前払い！」と設定するのが、最もシンプルで効果的な対策です。

—

3. 注意！「ヘッダーが届かない」という盲点

しかし、現場はそんなに甘くありません。たまに、この大切な「どこから来たか情報」が、ブラウザの設定やネットワークの都合で消えてしまうことがあるのです。

プライバシー重視のブラウザ設定: ユーザーが「自分の足跡を追わせたくない」と強く設定している場合、Refererが空っぽになることがあります。
社内プロキシやセキュリティソフト: 通信を中継する際、セキュリティ上の理由でヘッダーを削除する設定になっていることがあります。

「じゃあ、ヘッダーが空なら全部ブロックすればいいの？」というと、そうすると正規のユーザーまでサイトを使えなくなってしまいますよね。ここが腕の見せ所です。

—

4. 実践：現実的なフォールバック戦略（コード例）

私たちは「ヘッダーがない＝即遮断」ではなく、「ヘッダーがあるなら厳しくチェックし、ない場合は別の方法で補完する」という多層的な防御を設計します。

以下は、Webフレームワークなどで実装する際の、考え方のイメージコードです。

// 簡易的なCSRF検証ロジックの例
function isAuthorized(request) {
const origin = request.headers[‘origin’];
const referer = request.headers[‘referer’];
const expectedOrigin = ‘https://my-bank.com’;

// 1. Originヘッダーがあれば最優先で検証
if (origin) {
return origin === expectedOrigin;
}

// 2. Refererヘッダーで検証（Refererはパスまで含むのでドメイン部分を抽出して比較）
if (referer) {
return referer.startsWith(expectedOrigin);
}

// 3. 【重要】ヘッダーがない場合のフォールバック（ここが命！）
// ヘッダーが取れない環境を想定し、別途「CSRFトークン」という
// 「本人しか知らない秘密の合言葉」をリクエストに含める方式を併用します。
return validateCsrfToken(request.body.csrf_token);
}

—

まとめ：セキュリティは「多層」で守る

今回の教訓は、「一つの防犯グッズ（ヘッダー検証）を過信しないこと」です。

1. まずは基本: Origin/Refererヘッダーをチェックし、怪しい通信を弾く。
2. 逃げ道を作る: ヘッダーが消えてしまうケースがあることを理解し、必ず「CSRFトークン」のような、別の本人確認手段をバックアップとして用意する。

セキュリティは、鍵を一つ増やすだけではなく、家の構造そのものを強くしていく作業に似ています。最初は難しく感じるかもしれませんが、こうして一つひとつ「もしこうなったら？」と想像を膨らませることが、あなたを一流のエンジニアへ近づけてくれます。

一歩ずつ、着実に。一緒にWebの世界を安全にしていきましょう！