CookieのSameSite属性とは？Strict・Lax・Noneの違い・既定値・設定方法・診断基準

CookieのSameSite属性とは

CookieのSameSite属性とは、サーバーが Set-Cookie ヘッダーで発行するCookieに付ける属性で、「別のサイトから始まったリクエストに、このCookieを付けて送るか」をブラウザに指示するものです。値は Strict・Lax・None のいずれかです。

Set-Cookie: PHPSESSID=…; path=/; secure; HttpOnly; SameSite=Lax

SameSite属性を適切に設定すると、悪意あるサイトが利用者のブラウザに勝手にリクエストを送らせ、ログイン中の権限で処理を実行させる クロスサイト・リクエスト・フォージェリ（CSRF） の被害を大きく抑えられます。

OWASP ASVS 5.0.0 は V3.3.2（Level 2）で「各Cookieの SameSite 属性値が、Cookieの目的に応じて設定されていること」を求めています。OWASP Session Management Cheat Sheet は、セッションCookieには Strict（推奨）または Lax を明示し、ブラウザの既定値に頼らないよう勧めています。

SameSiteのStrict・Lax・Noneの違い

値ごとの送信範囲

「同じサイト」の範囲

ここでの「サイト」は、登録可能ドメイン（eTLD+1）とスキームの組み合わせです。www.city.example.lg.jp と shinsei.city.example.lg.jp は同じサイトとみなされる一方、Public Suffix Listで区切られる別ドメイン（例：異なる github.io サブドメイン）は別サイトです。このため、同一サイト内のサブドメインからの攻撃は SameSite では防げません。

SameSite属性が無い場合の既定値

Chrome は バージョン80（2020年）以降、SameSite が無いCookieを Lax として扱っています（トップレベルのPOSTについては、設定から2分以内に限り送信を許す一時的な緩和措置があります）。MDNは「一部のブラウザは SameSite 未指定時に Lax を既定値とする」と説明しており、ブラウザ間で既定の動作がそろっているわけではありません。つまり属性を省略すると、利用者のブラウザによって保護の有無が変わります。そのため、目的に応じた値を 明示 することが求められます。

自治体サイトでSameSiteの値を選ぶ考え方

自治体公式サイトでは、トップページや記事ページ自体はログイン不要で、Cookieは主に次の用途で発行されます。

• CMSや電子申請・施設予約システムのセッション
• ロードバランサーの振り分け（スティッキーセッション）
• 文字サイズ・背景色・言語切替などのアクセシビリティ設定

多くの場合、セッションCookieは Lax、表示設定も Lax で問題ありません。ロードバランサーのCookieは、製品によってクロスサイト用（SameSite=None; Secure）と通常用の2種類が発行されることがあり、通常用に属性が無いとこの項目が△になります。製品の設定で属性を付けられるかを確認してください。

CookieのSameSite属性についてよくある誤解

• 「SameSiteを付ければCSRF対策は完了」：同一サイト内（他のサブドメイン）からの攻撃、GETで状態を変更する実装、Lax で許されるトップレベル遷移などは防げません。ASVSやIPAが求めるCSRFトークン、再認証、送信元確認と組み合わせる「多層防御」の一部です。IPA「安全なウェブサイトの作り方」のCSRF対策（6-(i)）は、トークン・再認証・Refererの確認を根本的解決としています。フォームのトークンの有無は「POSTフォームのCSRF対策兆候」で確認します。
• 「Strictが常に最善」：Strict では、メールや他サイトのリンクから訪れたときにログイン状態が引き継がれず、利用者が再ログインを求められます。セッションCookieは Lax で運用し、重要操作の確認画面だけ別の Strict Cookieで保護するといった設計もあります。
• 「Noneは危険な値」：外部サイトに埋め込まれる仕組み（埋め込み型の予約ウィジェット、SSO連携など）では None; Secure が必要な場合があります。用途に合っていれば正しい設定です。

CookieのSameSite属性の診断基準（セキュリティAIチェッカー）

取得方法

1. トップページ（転送後の最終応答）と、トップページの同一オリジンリンクから選んだ最大4ページ（ログイン・管理・マイページ系を優先）を GETのみ で取得します。ログアウト・削除系のURLや静的ファイルは巡回しません。
2. 各最終応答の Set-Cookie を1件ずつ収集します（転送途中の応答のCookieは観測しません）。
3. 削除用のSet-Cookie（Max-Age=0 以下、または過去の Expires）は除外します。
4. 有効なCookieが0件なら対象外（na）です。

判定条件

• 値は大文字小文字を区別せず、= の前後の空白を許容して判定します。SameSite=Lax_ のような不正な値は「未設定」と同じ扱いです（ブラウザも不正な値は無視します）。
• この項目は「明示しているか」を評価します。None を使う場合の Secure 必須要件は「SameSite=NoneとSecureの組み合わせ」で評価します。
• 値が用途に合っているか（たとえばセッションCookieに None を使う必要があるか）は公開情報からは判断できないため、×ではなく△としています。

自治体サイトでの判定例

SameSite属性がないとどんなリスクがあるか

• CSRFによる意図しない操作：ログイン中の利用者が攻撃者のページを開いただけで、裏で自治体サイトへのフォーム送信が行われ、登録情報の変更、施設予約の取消、メールマガジンの登録変更などが実行されます（CWE-352）。SameSite が無いと、ブラウザによってはこのリクエストにセッションCookieが付与されます。
• ログインCSRF・クリックジャッキングとの組み合わせ：ASVSも SameSite を、UIリドレス攻撃（クリックジャッキング）やブラウザ経由のリクエスト偽造の影響を抑える手段として位置付けています。
• ブラウザ差による保護の不均一：既定値に依存すると、ある利用者は守られ、別の利用者は守られないという状態になり、検証や説明が難しくなります（CWE-1275）。

CookieのSameSite属性の設定方法（PHP・Apache・nginx・IIS・Next.js）

PHP

<?php
// php.ini / .user.ini（PHP 7.3以降）
// session.cookie_samesite = "Lax"

session_set_cookie_params([
    'path' => '/', 'secure' => true, 'httponly' => true, 'samesite' => 'Lax',
]);
session_start();

PHP 7.2以前では samesite オプションが無いため、PHPのバージョンアップが基本対応です。

Apache（補助策）

<IfModule mod_headers.c>
  Header always edit Set-Cookie "(?i)^(?!.*;\s*samesite\s*=)(.*)$" "$1; SameSite=Lax"
  Header edit Set-Cookie "(?i)^(?!.*;\s*samesite\s*=)(.*)$" "$1; SameSite=Lax"
</IfModule>

Apacheは応答ヘッダーを2つの内部表で管理しており、CGI・FastCGI（mod_proxy_fcgi）由来の Set-Cookie は always 側、それ以外の多くは既定（onsuccess）側に入るため、両方の条件で記述します。

nginx（リバースプロキシ）

proxy_cookie_flags ~ samesite=lax;

IIS（ASP.NET 4.7.2以降）

<system.web>
  <sessionState cookieSameSite="Lax" />
  <httpCookies sameSite="Lax" requireSSL="true" httpOnlyCookies="true" />
</system.web>

Next.js（Vercel）

import { cookies } from "next/headers";

(await cookies()).set("session", token, { sameSite: "lax", secure: true, httpOnly: true, path: "/" });

段階的な導入と注意点

1. Cookieを用途ごとに分類します：①セッション・認証（Lax または Strict）、②表示設定など（Lax）、③外部サイトからの埋め込み・SSO・決済の戻りで必要なもの（None; Secure）。
2. 外部の決済代行・SSO（SAML等）から POSTで戻ってくる 画面がある場合、Lax にするとセッションCookieが送られず、ログイン状態が失われることがあります。該当する画面はテスト環境で必ず確認してください。
3. Webサーバーでの一律付与は③の用途を壊す可能性があるため、アプリケーション側での個別設定を優先します。
4. 確認します。

curl -sSI https://www.city.example.lg.jp/ | grep -i '^set-cookie'

5. SameSite に加え、状態を変更する処理にはCSRFトークンの検証を実装してください。

HTTPSでのみ送信させる「CookieのSecure属性」、JavaScriptからの読み取りを防ぐ「CookieのHttpOnly属性」とあわせて設定するのが基本です。

よくある質問（FAQ）

参考資料

• OWASP ASVS 5.0.0 V3 Web Frontend Security（3.3.2）
• OWASP Session Management Cheat Sheet
• OWASP WSTG-SESS-02 Testing for Cookies Attributes
• MDN Set-Cookie
• web.dev SameSite cookies explained
• draft-ietf-httpbis-rfc6265bis
• IPA 安全なウェブサイトの作り方 1.6 CSRF

「CookieのSameSite属性」と関連する診断項目

• POSTフォームのCSRF対策兆候high
• SameSite=NoneとSecureの組み合わせhigh
• CookieのSecure属性high
• CookieのHttpOnly属性high
• Cookieの有効期間が過度に長くないmedium
• CookieのDomain/Path範囲medium
• Cookie名・値のサイズ上限medium
• パスワードをPOSTで送信critical