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

郵便ポストに「合言葉」を。CSRFを防ぐカスタムヘッダーの魔法

こんにちは!ネットワークの深淵を愛するインフラエンジニアです。

今日は、Web APIの世界で非常に重要でありながら、意外と見過ごされがちな「CSRF(クロスサイト・リクエスト・フォージェリ)」という悪意ある攻撃から身を守るための、とっておきのテクニックをお話しします。

「CSRFって何だか難しそう……」と思ったあなたも大丈夫。まずは、身近な「郵便配達」の話から一緒に紐解いていきましょう。

—

1. CSRFという名の「なりすまし郵便」

想像してみてください。あなたは銀行に「口座の残高を全額送金してください」という手紙を出したとします。本来なら、この手紙は本人しか出せませんよね。

しかし、もし悪意のある誰かが、あなたの筆跡やスタンプを盗み出し、銀行に対して勝手に「送金依頼書」を送りつけたらどうなるでしょう?銀行は「お、いつものお客さんからだ」と信じ込んで、お金を動かしてしまいます。

これがWebの世界でいう CSRF(クロスサイト・リクエスト・フォージェリ) です。

ブラウザには「一度ログインしたサイトには、自動的に認証情報(クッキーなど)を添えてリクエストを送る」という便利な機能があります。攻撃者はこの機能を悪用して、「ユーザーが意図しないリクエスト」を、まるでユーザー本人が操作したかのようにサーバーへ送りつけるのです。

—

2. 「カスタムヘッダー」という名の秘密の合言葉

では、この「なりすまし」をどうやって見破ればいいのでしょうか?

そこで登場するのが カスタムヘッダー です。

銀行の例で言えば、ただの手紙ではなく、「事前に銀行とあなただけが知っている秘密の暗号(合言葉)」が封筒に書かれていない限り、絶対に受理しないというルールを設けるのです。

ブラウザの通常のHTMLフォーム送信では、この「秘密の合言葉(カスタムヘッダー)」を自由に付け加えることができません。逆に言えば、そのヘッダーが付いているリクエストは、間違いなく「専用のプログラム(APIクライアント)」から送られたものだと判断できるわけです。

—

3. 実践!カスタムヘッダーで身を守る

では、実際にどのように実装するのか見ていきましょう。ここでは、よく使われる X-Requested-With というヘッダーを例にします。

サーバー側のチェック(例:PHP)

サーバー側では、送られてきたリクエストの中にその「合言葉」があるかを確認します。

<?php
// リクエストヘッダーから「X-Requested-With」の値を取得
$requestedWith = $_SERVER['HTTP_X_REQUESTED_WITH'] ?? '';

// 合言葉が一致するかチェック!
if ($requestedWith !== 'XMLHttpRequest') {
    // 合言葉がない場合は、不正なリクエストとして処理を停止
    header('HTTP/1.1 403 Forbidden');
    exit('不正なリクエストです。');
}

// ここから先は安全な処理を実行
echo "通信成功!安全なアクセスです。";
?>

クライアント側の送信(例:JavaScript)

フロントエンドからAPIを叩くときは、必ずこのヘッダーを添えてあげます。

fetch('/api/transfer', {
    method: 'POST',
    headers: {
        // ここが「合言葉」になります!
        'X-Requested-With': 'XMLHttpRequest',
        'Content-Type': 'application/json'
    },
    body: JSON.stringify({ amount: 10000 })
});

—

4. なぜこれで攻撃を防げるのか?

ここが重要なポイントです。

悪意のある攻撃者が、別のサイトからあなたの銀行サイトへ勝手にリクエストを送ろうとしても、攻撃者のサイト上のJavaScriptからは、自分のサイトとは異なるドメイン(銀行サイト)に対して、自由にカスタムヘッダーを付与することはできないというブラウザの強力な制約(CORS)が働きます。

つまり、攻撃者は「なりすまし」はできても、「秘密の合言葉(カスタムヘッダー)」を知らないため、銀行のゲートを突破できないのです。

—

まとめ:一歩ずつ、堅牢なシステムへ

今回ご紹介したカスタムヘッダーによる対策は、いわば「玄関に鍵をかける」ような、非常に基本的でありながら強力な防御策です。

1. CSRFは「自動送信機能」を悪用したなりすまし攻撃
2. カスタムヘッダーは、APIとクライアントだけの「秘密の合言葉」
3. ブラウザの制約により、攻撃者はその合言葉を付与できない

もちろん、Web開発の世界には他にも「トークンを使った認証」など、より高度な防御策がたくさんあります。ですが、まずは今日学んだ「ヘッダーでリクエストを検証する」という感覚を大切にしてみてください。

インフラやネットワークの世界は、こうした「誰が、どこから、どんな合言葉で来たのか?」を確認する積み重ねでできています。一つひとつの仕組みを丁寧に紐解いていけば、必ず強固な要塞を築くことができますよ。

それでは、また次回の深淵でお会いしましょう!応援しています!

コメント

タイトルとURLをコピーしました