【入門編】 SameSite Cookie属性の適切な設定とセキュリティ効果 – オフェンシブセキュリティ & リバースエンジニアリング防御ガイド

こんにちは！Webアプリケーションの開発や、インフラの管理を任されるようになると、「セキュリティ」という言葉が急に重くのしかかってきますよね。「クロスサイトリクエストフォージェリ（CSRF）」とか「SameSite属性」とか、耳慣れない専門用語が出てくると、それだけで頭がクラクラしてしまう方も多いのではないでしょうか。

でも、安心してください。セキュリティの仕組みも、基本の考え方は私たちの日常生活にある「防犯」と同じなんです。今回は、Cookieのセキュリティを守るための強力な盾である「SameSite属性」について、身近な例えを交えながら、一歩ずつ優しく紐解いていきましょう！

—

1. 家の鍵と合鍵の関係で理解する「CookieとCSRF」

まずは、Webの世界でCookieがどう使われているか、そしてなぜ狙われるのかを考えてみます。

あなたが自分の家に住んでいると想像してください。玄関の鍵を開けて家に入るたびに、毎回身分証明書を出して本人確認をするのは面倒ですよね？だから、一度ログイン（鍵を開けて入室）したら、信頼の証として「合鍵（セッションCookie）」をポケットに入れてもらう仕組みになっています。この合鍵があれば、家の中（Webサイト）で自由に買い物をしたり、設定を変えたりできます。とても便利ですよね。

しかし、ここに巧妙な泥棒（攻撃者）がやってきます。

泥棒は、あなたが「信頼している別の場所（怪しいショッピングサイトや悪意あるブログ）」にあなたを誘導し、あなたのポケットにある合鍵を勝手に使って、あなたのお金で勝手にお買い物をする注文書をこっそりあなたの家（標的サイト）に投げ込ませるのです。これが、CSRF（クロスサイトリクエストフォージェリ）という攻撃の正体です。

あなたの意思とは関係なく、ポケットの中の合鍵が勝手に使われてしまう――これが従来のCookieが抱えていた大きな弱点でした。

—

2. 泥棒の侵入を防ぐ「SameSite属性」という名の番犬

この「合鍵が勝手に使われる問題」を防ぐために生まれたのが、今回主役となるSameSite属性です。

SameSite属性は、簡単に言うと「この合鍵を使っていいのは、今いる家の中からの依頼だけだよ！よその家から飛んできた依頼には使わせないよ！」と、Cookieに設定する番犬のようなものです。

この番犬の働き方には、大きく分けて Strict、Lax、None という3つのモードがあります。それぞれの動きを詳しく見ていきましょう！

Strict（厳格モード）：「身内以外は絶対にシャットアウト！」

どういう動き？：あなたがどのサイトからリンクを踏んできたとしても、今いるサイトと違う場所（外部サイト）から飛んできたリクエストの場合、Cookieは一切送信されません。
例え話：「うちの家族以外は、どんなに用事があっても玄関の外でお断り！」という徹底ぶりです。
メリット：セキュリティ面では最強です。CSRF攻撃は完全に防げます。
デメリット：例えば、外部のニュースサイトに貼られたあなたのサービスのリンクをクリックしてログインページに飛んだとき、Cookieが送られないため「あれ、ログアウト状態になっちゃった？」とユーザーが戸惑う原因になります。

Lax（緩和モード・デフォルト）：「リンクを踏んでの訪問ならOK、勝手な裏技はNG！」

どういう動き？：外部サイトからのアクセスであっても、ユーザーが明示的にリンクをクリックして移動してきた場合（例: GETリクエスト）はCookieを送信します。ただし、画像を勝手に読み込ませたり、裏側でこっそりデータを送信させたりするような処理（例: POSTリクエストなど）ではCookieを送信しません。
例え話：「チャイムを鳴らして（リンクをクリックして）ちゃんと言葉を交わして入ってくるお客さんなら通すけど、勝手に窓から荷物を投げ込もうとする不審者は通さないよ！」というイメージです。
メリット：ユーザビリティを損なわずに、大半の厄介なCSRF攻撃を防ぐことができます。現代の多くのブラウザで、デフォルト（何も指定しない場合に選ばれる設定）として採用されています。
デメリット：GETリクエストを悪用した一部の攻撃に対しては、完全に無力というわけではありませんが、実用上非常にバランスの取れた設定です。

None（制限なし）：「どこからでも合鍵を使います！」

どういう動き？：外部サイトからのリクエストであっても、条件なしで常にCookieを送信します。
例え話：「合鍵はどこで誰が使ってもOKです！」という、防犯的にはかなり危うい状態です。
注意点：この設定を使う場合、ブラウザの仕様により Secure属性（HTTPS通信でのみ送信する設定） を同時に指定することが必須となります。これがないと、現代のブラウザでは自動的に弾かれてしまいます。
いつ使うの？：例えば、外部のウィジェットや決済システムなど、どうしても他のドメインからCookieを含んだ通信を送受信する必要がある正当な理由がある場合のみ使用します。

—

3. 実務でどう設定する？コード例で確認しよう

それでは、実際にサーバーからブラウザへCookieを渡す際、どのようにSameSite属性をコードに記述すればよいかを見てみましょう。PHPを例に挙げてみます。

実務の開発では、ログイン処理やセッション発行のプログラム内で以下のようにヘッダーを送信します。

<?php
// PHPでセキュアなCookieを発行するサンプルコード

$cookie_name = "session_id";
$cookie_value = "secret_token_12345";
$expire = time() + (86400 * 30); // 有効期限：30日後
$path = "/";
$domain = "example.com";
$secure = true;     // true: HTTPS通信（暗号化された通信）でのみCookieを送信する
$httponly = true;   // true: JavaScriptからのアクセスを禁止し、XSS攻撃による盗難を防ぐ
$samesite = "Lax";  // "Strict", "Lax", "None" のいずれかを指定

// PHP 7.3.0以降で利用できる setcookie のオプション配列構文
setcookie($cookie_name, $cookie_value, [
    'expires' => $expire,
    'path' => $path,
    'domain' => $domain,
    'secure' => $secure,
    'httponly' => $httponly,
    'samesite' => $samesite,
]);

echo "セキュアなCookieが設定されました！";
?>

💡 コードのポイント解説

'samesite' => 'Lax': ここで番犬のモードを指定しています。通常のWebサービスであれば、まずはここをLaxにしておくのが王道の対策です。
'secure' => true: SameSite属性をNoneにする場合はもちろん、現代のWeb開発では通信の盗聴を防ぐためにHTTPSが必須です。この設定も必ずセットで行いましょう。
'httponly' => true: Cookie自体に直接関係はしませんが、JavaScriptからCookieを盗み出す攻撃（XSS）を防ぐための相棒のような設定です。セットで覚えておきましょう。

—

4. 最後に：一歩ずつ安全なWebを作っていこう！

今回は、SameSite属性の仕組みと、CSRF防御における役割を身近な例えと共にお伝えしました。

外部からの不審なリクエストから合鍵を守るためには SameSite属性 が強力な盾になること。
基本的には Lax を選び、必要に応じて Strict や None（※要Secure） を使い分けること。
実装時には setcookie などの関数で適切にパラメーターを渡すこと。

セキュリティの対策は、最初はいろいろな用語が出てきて難しく感じるかもしれませんが、一つひとつの意味を紐解いていけば、決して越えられない壁ではありません。

今日学んだ知識をあなたのプロジェクトに少しずつ取り入れて、より安全で信頼されるWebアプリケーションを一緒に作っていきましょう！一歩ずつの積み重ねが、あなたを頼もしいエンジニアへと成長させてくれますよ。それではまた次回の記事でお会いしましょう！