【実務・中級編】Cross-Site Request Forgery (CSRF) 対策としてのSameSite属性とトークン – アプリケーションセキュリティ & 安全な開発防御ガイド

CSRFは「死んだ」のか？：SameSite属性とトークンで防ぐ、ブラウザの「お節介」の悪用

「CSRFなんて今の時代、SameSite属性さえあれば完璧でしょ？」

もし君がそう思っているなら、少しだけ立ち止まってほしい。確かにモダンなブラウザは賢くなった。しかし、セキュリティの現場で我々が見るのは、技術の進化ではなく「設定の不備」や「レガシー環境との妥協」によって引き起こされる、泥臭いインシデントの数々だ。

今日は、CSRF（Cross-Site Request Forgery）という古くて新しい脅威について、教科書には載っていない「実務的な防壁」の話をしよう。

—

1. CSRFの本質：ブラウザの「親切心」を悪用する攻撃

CSRFの恐ろしさは、攻撃者が君のパスワードを盗む必要すらない点にある。攻撃者は、「ログイン中のユーザーのブラウザが、自動的にCookieを付与してリクエストを送ってしまう」という、HTTPの仕様そのものを悪用する。

攻撃のPoC（概念実証）の裏側

想像してほしい。君が管理画面で「管理者権限の削除」を行うボタンを押す際、リクエストが POST /admin/delete-user?id=123 だったとする。攻撃者は、被害者がログインした状態で、自作の悪意あるサイトにアクセスさせる。

被害者のブラウザは「ああ、このユーザーは銀行にログイン中だな。Cookieを付けてあげなきゃ（親切心）」と判断し、リクエストにセッションCookieを添えて送信する。結果、サーバー側は「正規のユーザーからの操作だ」と勘違いし、処理を実行してしまう。これがCSRFの恐怖だ。

—

2. 第一の防壁：SameSite属性の現実的設定

現代のフロントエンド開発において、Set-Cookie ヘッダーに SameSite 属性を付与することは必須だ。

Strict: 同一サイトからのリクエストのみCookieを送る。最も堅牢だが、外部サイトのリンクから遷移した際にログイン状態が引き継がれない（ユーザー体験が落ちる）。
Lax: デフォルト設定。トップレベルのナビゲーション（リンククリックなど）では許可されるが、POSTリクエストではCookieが送られない。

実務的な設定（Nginx例）:
サーバーサイドで一括制御する場合、Nginxの設定にこう書き込む。

Nginxのヘッダー設定で強制的にSameSiteを付与する
最新ブラウザではLaxがデフォルトだが、明示することが重要
add_header Set-Cookie “Path=/; HttpOnly; Secure; SameSite=Lax”;

ただし、SameSiteだけに依存してはいけない。 Safariの古いバージョンや、特定の環境下では意図した挙動にならないケースがあるし、そもそもAPIエンドポイントがクロスドメインを許容している設計だと、SameSiteの防壁は無力化されることがあるからだ。

—

3. 第二の防壁：Anti-CSRFトークンという「最強の盾」

SameSiteがブラウザ側の制御なら、Anti-CSRFトークンはアプリケーション側の制御だ。これは、フォームごとに「推測不可能なワンタイムトークン」を発行し、サーバー側で照合する仕組みだ。

PHPでの実装例：堅牢なトークン検証

—

4. シニアエンジニアからの教訓：盲点を突かれないために

1. 「GETで状態変更をしない」という鉄則:
CSRFはPOSTだけでなく、GETリクエストでも発生しうる。GET /delete?id=1 のようなURLを画像タグの src に仕込まれたら、ユーザーがページを開くだけで処理が走る。「GETは読み取り専用、状態変更はPOST/PUT/DELETE」というRESTの基本を死守しろ。
2. APIはAuthorizationヘッダーを使う:
最近のSPA（React/Vueなど）とAPIの構成であれば、Cookie認証を捨てて、Authorization: Bearer を採用するのも手だ。ヘッダーによる認証であれば、ブラウザが自動的に付与するCookieの悪用（CSRF）という土俵自体がなくなる。
3. WAFを過信しない:
「WAFで防いでいるから大丈夫」という言葉を、私は何度も聞いてきた。だが、WAFは通信経路の検知であり、アプリケーションのロジックの脆弱性までは救えない。コードで防ぐ（Defense in Depth：多層防御）ことが、唯一の正解だ。

最後に

セキュリティ対策は「一度やれば終わり」というものではない。ブラウザの仕様変更、新しいフロントエンドフレームワークの導入、そして攻撃手法の進化。これらに合わせて、君のコードもアップデートし続ける必要がある。

まずは、今の君のプロジェクトで SameSite=Lax が漏れていないか、そして重要なPOST処理にトークンチェックが実装されているか。今すぐ確認してくれ。それが、プロのエンジニアの第一歩だ。