【入門編】CSRF対策としてのカスタムHTTPヘッダー検証とCORSの併用戦略 – アプリケーションセキュリティ & 安全な開発防御ガイド

エンジニアの皆さん、こんにちは。現場で泥臭くコードを書き、時には深夜のインシデント対応で汗を流す「セキュリティの現場監督」です。

今日は、Webアプリ開発の登竜門であり、かつベテランでも油断すると足元をすくわれる「CSRF（クロスサイト・リクエスト・フォージェリ）」と、それを防ぐための最強タッグ「カスタムヘッダー×CORS」についてお話しします。

教科書には難しい言葉が並んでいますが、実はこれ、「家の防犯」に例えると驚くほどシンプルなんです。さあ、一歩ずつ紐解いていきましょう！

—

1. CSRFという名の「泥棒」の手口を知ろう

CSRFは、日本語で「クロスサイト・リクエスト・フォージェリ」と言います。簡単に言うと、「あなたになりすまして、勝手に悪さをする攻撃」のことです。

泥棒のメカニズム

あなたが銀行のサイトにログインして、「送金」ボタンを押すとしますよね。この時、ブラウザは「ログインした人だ！」という証明書（クッキー）を自動的に銀行へ送ります。

攻撃者は、あなたがログインしている状態で、悪意のあるサイト（罠サイト）をあなたに開かせます。すると、罠サイトがこっそりあなたのブラウザを操り、裏側で「送金ボタン」を勝手に押させるのです。ブラウザは「いつもの証明書」を付けて送るため、銀行側は「本人が頼んだことだ」と勘違いして送金を実行してしまいます。

これがCSRFの恐ろしさです。「本人のブラウザが勝手にやる」ので、サーバー側からは見抜きにくいんですね。

—

2. 最初の防波堤：カスタムHTTPヘッダーという「合言葉」

CSRFを防ぐ古典的な手法は「トークン」を使うことですが、最近のモダンなSPA（ReactやVueなど）開発では、カスタムHTTPヘッダーを検証するのが主流です。

これは、家に入る時に「玄関の鍵とは別に、合言葉を言わなきゃいけないルール」を作るようなものです。

ブラウザの標準的な機能（HTMLの

タグなど）では、リクエストに独自のヘッダーを追加することができません。つまり、攻撃者の罠サイトからリクエストを飛ばしても、正しい「合言葉（ヘッダー）」が付いていないため、サーバーは即座に「お前は偽物だ！」と弾くことができるわけです。

実装のヒント（サーバー側のチェック例）

例えば、全ての通信に X-Requested-With: MySecureApp というヘッダーを必須にするとします。

// Node.js (Express) での簡単なチェック例
app.use((req, res, next) => {
const customHeader = req.get(‘X-Requested-With’);

// 重要な処理の前に「合言葉」をチェック！
if (req.method !== ‘GET’ && customHeader !== ‘MySecureApp’) {
return res.status(403).send(‘不正なリクエストです。合言葉が違います。’);
}
next();
});

—

3. 次の防波堤：CORSという「門番」

次に登場するのがCORS（Cross-Origin Resource Sharing）です。これは「どこの家からの訪問なら受け入れるか」を管理する、非常に優秀な門番です。

カスタムヘッダーが「合言葉」なら、CORSは「許可証（ホワイトリスト）」です。たとえ誰かが悪巧みをしようとしても、あなたのサーバーが「このドメイン以外からのアクセスは許さない！」と門番に指示していれば、そもそも通信そのものをブロックしてくれます。

CORSの設定サンプル

サーバー側で、信頼できるドメインだけを許可するように設定しましょう。

// CORS設定の例
const cors = require(‘cors’);

const corsOptions = {
origin: ‘https://myapp.com’, // このドメイン以外からのアクセスは門前払い
methods: [‘GET’, ‘POST’, ‘PUT’, ‘DELETE’],
allowedHeaders: [‘Content-Type’, ‘X-Requested-With’], // カスタムヘッダーも許可リストに！
credentials: true // クッキーを使うならここをtrueに
};

app.use(cors(corsOptions));

—

4. なぜ「多重防御」が必要なのか？

「CORSがあるならカスタムヘッダーはいらないのでは？」と思うかもしれません。しかし、現場のセキュリティは「何重にも鍵をかける」ことが鉄則です。

CORSは、ブラウザの力を使って「そもそも通信をさせない」ための第一の壁。
カスタムヘッダーは、もしCORSをすり抜けるような未知の脆弱性や設定ミスがあった場合でも、「合言葉がないから処理しない」と決める第二の壁。

この二段構えにしておくことで、防御の強度は格段に上がります。泥棒が窓を割っても、中には頑丈な金庫が待ち構えている状態を作るのです。

—

最後に：完璧なセキュリティなんてないからこそ

最後に一つだけ覚えておいてください。セキュリティに「これで100%安心」というゴールはありません。攻撃者は常に新しい手口を考えています。

しかし、こうして「なぜこの対策が必要なのか？」「このヘッダーにはどんな役割があるのか？」を一つずつ理解して積み上げていく姿勢こそが、最高峰のエンジニアへの第一歩です。

まずは今日、皆さんのアプリケーションのヘッダー設定を見直してみてください。「あ、このヘッダー、何のためにあるんだっけ？」と立ち止まること。それが最強のセキュリティ対策の始まりですよ！

また次回の記事でお会いしましょう。現場からは以上です！