なぜ今さら「SameSite」なのか？CSRFを過去のものにするための現場の鉄則
「CSRF（クロスサイトリクエストフォージェリ）対策？ まあ、トークン入れてるし大丈夫でしょ」。
もし君がそう思っているなら、一度立ち止まってほしい。トークンによる対策は確かに王道だが、実装漏れやトークンの検証ロジックの不備、あるいはHTTPヘッダーの取り扱いで簡単に穴が空く。
今日語るのは、ブラウザの挙動という「最後の砦」を制御するSameSite属性についてだ。これを正しく理解していないと、現代のWebアプリケーションでは「鍵をかけていない扉」を放置しているのと同じだと言える。
—
1. SameSite属性の「正体」と選択のロジック
SameSite属性は、クッキーがクロスサイトリクエスト（ドメインを跨いだリクエスト）で送信されるか否かを制御する。この属性には3つの値があるが、現場で考えるべきは実質2つだ。
Strict: 最強の防壁。同じサイトからのリクエスト以外、たとえリンクをクリックして遷移した場合でもクッキーは送信されない。堅牢だが、UX（ユーザー体験）が犠牲になることも多い。Lax: 現代のデフォルトにして最適解。 サイト遷移（GETリクエスト）時はクッキーを送信し、それ以外の危険なリクエスト（POST/PUT等）時はブロックする。None: クロスサイト環境でも問答無用で送信する。これを使うならSecure属性（HTTPS必須）が必須だ。
「なぜLaxで十分なのか？」という問いに答える
実務では Strict が推奨されがちだが、これを使うと「外部サイトのリンクから自分のサイトへ飛んできたユーザーが、ログイン状態ではないとみなされる」という悲劇が起きる。だからこそ、現代のWebアプリケーションは「デフォルトLax」で設計し、API通信やAjaxなどは別途トークン検証で守るのが、泥臭いインシデントハンドリングの現場で見つけた結論だ。
—
2. 実装のセキュア・サンプル
理屈はわかっても、実装でミスれば意味がない。以下に、現代のスタックで最低限守るべき実装例を示す。
PHP (フレームワークに頼らず設定する場合)
setcookie 関数で、漏れなく属性を付与する。
time() + 3600,
‘path’ => ‘/’,
‘domain’ => ‘example.com’,
‘secure’ => true, // HTTPS必須
‘httponly’ => true, // JavaScriptからのアクセス禁止（XSS対策）
‘samesite’ => ‘Lax’ // ここが肝
]);
Nginx (アプリケーション層の手前で強制する)
アプリケーションコードに不安があるなら、インフラ層で強制的にヘッダーを書き換えるのも一つの手だ。
Nginx設定ファイル
すべてのSet-CookieヘッダーにSameSite=Laxを強制付与する
proxy_cookie_path / “/; HTTPOnly; Secure; SameSite=Lax”;
—
3. レガシーブラウザという「悪夢」への対処
「古いブラウザはどうするんだ？」という質問が飛んできそうだが、安心しろ。SameSite 属性を解釈できない古いブラウザは、属性そのものを無視するだけだ。 つまり、防御が働かないだけで、攻撃されるリスクはこれまでと変わらない。
重要なのは、「SameSiteがあればCSRFは完全に防げる」と過信しないことだ。
- 多層防御の徹底: SameSiteはあくまでブラウザベースの保護。サーバー側では必ず
X-CSRF-Tokenなどの独自ヘッダーを要求し、その検証を厳格に行うこと。 - Referer/Originチェック:
Strict/Laxを突破しようとするリクエストに対して、Refererヘッダーを検証し、信頼できるドメイン以外からのPOSTを弾くロジックをバックエンドに仕込んでおく。これが最後の防波堤になる。
—
セキュリティチーフからの助言
最後に一つだけ覚えておいてほしい。セキュリティの仕事は「完璧な城」を作ることではなく、「攻撃者がコストを割くのを諦める防壁」を配置し続けることだ。
SameSite属性の設定は、一行追加するだけで攻撃の難易度を劇的に跳ね上げることができる。これほどコスパの良いセキュリティ対策は他にない。今日このブログを読み終えたら、すぐ自社のプロジェクトのクッキー設定を確認してくれ。SameSite が設定されていない、あるいは None になっているなら、それは「直ちに修正すべき負債」だ。
現場からは以上だ。次は「XSSを許さないCSP（Content Security Policy）の現実的な運用」について話すとしよう。また会おう。
コメント