WEBサイトCookieの設定にSameSite=Laxを書いても、後から読まれる設定に置き換えられて応答に付かないことがある ── ログインのCookieを応答のヘッダーで確かめる13項目（2026年11月時点）
Cookieの設定にSameSite=Laxを書いても、後から読まれる設定に置き換えられて応答に付かないことがある ── ログインのCookieを応答のヘッダーで確かめる13項目（2026年11月時点）
目次
- 01 何が書かれているか — SameSiteは、Cookieを「他のサイトからの要求にも付けるか」を決める属性で、書かなかったときの扱いはブラウザごとに違う
- 02 なぜ・背景 — 書いた設定が、後から読まれる設定に置き換えられると、応答に出ない
- 03 用語 — 「サイト」「トップレベルの移動」「安全なメソッド」を先にそろえる
- 04 型別 — 当てはまるサイト、この記事が確かめていないこと、確かめる手順
- 05 明日、担当サイトで確認できること
- 06 代替・他の選択肢 — 確かめ方と、SameSiteだけに頼らない守り方
- 07 当サイトで確かめたこと — 設定に書いたSameSiteは、応答に出ていなかった
- 08 このテーマは、ここまで — 「設定を書いた」から「応答で確かめた」へ、どう積み上げてきたか
- 09 この記事のまとめ
01 何が書かれているか — SameSiteは、Cookieを「他のサイトからの要求にも付けるか」を決める属性で、書かなかったときの扱いはブラウザごとに違う
引用について
この記事は、MDN Web DocsのSet-Cookieとクッキーの解説、IETFのCookie仕様の草案、Chromiumプロジェクトの「SameSite Updates」、web.dev、OWASP、PHPの公式マニュアルを、2026年11月7日に開いて確かめた内容を書いている。英文は原文のまま引いて日本語訳を添え、それ以外は筆者が日本語に直した要旨で書く。原文に無い筆者の読みは「筆者の読み」と書き分ける。05章のチェックリストは、筆者の整理である。
ログインの状態を保つCookieには、SameSiteという属性を付けられる。多くのサイトは「設定ファイルにSameSite=Laxと書いた」ところで作業を終える。しかし、設定に書いたことと、ブラウザへ実際に届く応答のSet-Cookieに属性が付いていることは、別の話である。後から読まれる設定が、先に書いた設定を置き換えることがあるからだ。
この記事は、SameSiteの意味を公式の資料で確かめ、設定を書いたあとに「応答で確かめる」手順を13項目にまとめる。当サイトでも、書いたはずの設定が応答に出ていなかった。その経緯は07章に書く。
SameSiteが決めること
MDNのSet-Cookieのページは、SameSite属性をこう説明している。
"Controls whether or not a cookie is sent with cross-site requests: that is, requests originating from a different site, including the scheme, from the site that set the cookie."
（日本語訳: Cookieを、サイトをまたぐ要求と一緒に送るかどうかを制御する。つまり、そのCookieを設定したサイトとは、スキームを含めて別のサイトから出た要求のことである。）
3つの値と、Cookieが送られる場面
値は3つある。Strictは、そのCookieを設定したサイトから出た要求にだけ付ける。Laxは、それに加えて、他のサイトからのリンクで移動してきたときなど、「安全な方法」でのページ全体の移動にも付ける。Noneは、サイトをまたぐ要求にも付ける。MDNは、Laxが付く条件を、次の2つにそろえて書いている。1つは、要求が「トップレベルの移動」であること。もう1つは、要求が安全なメソッドを使うこと（POST・PUT・DELETEは含まない）。次の表は、その説明を場面別に整理したものである。
| 場面 | Strict | Lax | None |
|---|---|---|---|
| 同じサイト内の移動 | 送られる | 送られる | 送られる |
| 他のサイトのリンクから来た移動（GET） | 送られない | 送られる | 送られる |
| 他のサイトからのフォーム送信（POST） | 送られない | 送られない | 送られる |
| 他のサイトの画像・iframe・fetch | 送られない | 送られない | 送られる |
Noneを使うときは、Secureも付けることが条件になる。MDNには、"The Secure attribute must also be set when using this value."（日本語訳: この値を使うときは、Secure属性も付けなければならない。）とある。
属性を書かなかったとき
MDNのSet-Cookieのページには、次の一文がある。
"Some browsers use Lax as the default value if SameSite is not specified: see Browser compatibility for details."
（日本語訳: SameSiteを指定しなかったとき、Laxを既定の値として使うブラウザがある。詳しくはブラウザの互換表を見ること。）
MDNのクッキーの解説ページは、"If no SameSite attribute is set, the cookie is treated as Lax by default."（日本語訳: SameSite属性を付けなかったCookieは、既定でLaxとして扱われる。）と、断定に近い形で書く。筆者は、前者の「そう扱うブラウザがある」のほうが事実に近いと読んでいる。OWASPが次のように書いているからだ。
"Chromium-based browsers treat cookies without a SameSite attribute as Lax, but Firefox and Safari do not, and older or embedded clients may ignore the attribute entirely."
（日本語訳: Chromium系のブラウザは、SameSite属性の無いCookieをLaxとして扱う。しかしFirefoxとSafariはそうではなく、古いクライアントや組み込みのクライアントは、この属性を完全に無視することがある。）
つまり、属性が付いていないCookieの扱いは、ブラウザごとに違う可能性がある。Chromeで問題なくログインできていても、別のブラウザでは別の扱いになりうる。これが、設定を書くだけでなく、応答に出すべき理由の1つである。
Chromeの告知と、「2分間」の例外
Chromiumプロジェクトの「SameSite Updates」のページは、2021年3月18日が最終更新と表示されている。そこには、こう書かれている。
"The flags #same-site-by-default-cookies and #cookies-without-same-site-must-be-secure have been removed from chrome://flags as of Chrome 91, as the behavior is now enabled by default."
（日本語訳: フラグ #same-site-by-default-cookies と #cookies-without-same-site-must-be-secure は、Chrome 91の時点でchrome://flagsから取り除かれた。この挙動が、既定で有効になったためである。）
Laxを既定とするのは「SameSiteを書かなかったCookie」の扱いで、そのCookieだけに2分間の例外がある。
"which allows these cookies to be sent on top-level cross-site POST requests if they are at most 2 minutes old."
（日本語訳: これは、これらのCookieを、作られてから2分以内であれば、サイトをまたぐトップレベルのPOST要求にも付けることを許す。）
この例外は、POSTで始まるログインの流れが壊れるのを避けるための一時的な措置で、MDNにも同じ趣旨の説明がある。SameSiteを書いたCookieには、この2分間の例外は適用されない。ただし、今のブラウザが同じ扱いかは、告知の日付が古いので、確かめていない。
仕様は、発行の手前の草案のまま
SameSiteは、2011年4月のRFC 6265には書かれていない。筆者が本文を開いて「SameSite」を数えたところ、0回だった。定義しているのは、改訂を目指す草案（RFC 6265bis）で、2026年11月7日にIETFのdatatrackerを開くと、最新はdraft-22、公開日は2025年12月1日、状態は「Active Internet-Draft」だった。同じページには、IESGの状態が「RFC Ed Queue」、RFC Editorの状態が「blocked: Final Approval Pending」と表示されていた。発行の手前の段階にあるが、この日の時点で、標準（RFC）になったとは、書かれていなかった。
02 なぜ・背景 — 書いた設定が、後から読まれる設定に置き換えられると、応答に出ない
設定に書いたのに、応答に出ていない。この食い違いは、特別なことではない。サイトには同じ値を決める場所が複数あり、読み込みの順番が後ろのものが、前のものを置き換える。その結果、設定ファイルの行を読むだけでは、最終的な応答が分からなくなる。当サイトで何が起きたかは、07章で書く。
設定を決める場所は、1つとは限らない
PHPの公式マニュアルを例にとる。セッションのCookieのSameSiteを決める設定session.cookie_samesiteの既定値は空の文字列で、PHP 7.3.0から使える。値の説明には、こう書かれている。
"An empty value means that no SameSite cookie attribute will be set."
（日本語訳: 空の値は、SameSite属性を一切付けないことを意味する。）
つまり、何も書かなければ、属性は付かない。さらに、セッションのCookieの設定は、関数でも変えられる。マニュアルのsession_set_cookie_paramsのページには、"If the samesite element is omitted, no SameSite cookie attribute is set."（日本語訳: samesiteの要素を省くと、SameSite属性は付かない。）とある。つまり、筆者の読みでは、後から呼ばれた処理が、samesiteを書かずにCookieの設定をまとめて指定すると、先に書いた設定があっても属性が付かないことがありうる。「指定しなかったものは付けない」という素直な動きである。
後から読まれる設定が、先の設定を置き換える
筆者の読みでは、サイトを動かす仕組み（CMSやフレームワーク）の多くは、起動するとき、設定を何段階かで読み込む。最初に基本の設定を読み、あとから、サイトごとの設定ファイルや部品の設定を読む。ある部品が、「セッションの設定」を1つのまとまりとして持っていて、起動の途中でそのまとまりを丸ごと作り直すと、その前に書いた個別の指定は消える。PHPのマニュアルのini_setのページにも、設定の値を実行の途中で書き換えられることが書かれている。値はそのスクリプトの実行中だけ保たれ、終わると元に戻る、という説明である。設定は、読み込みの途中で書き換わりうる。
この記事は、どのCMSのどの版で起きるかを調べたものではない。一般にそうなりうるという範囲で書く。自分のサイトで起きているかは、応答を見るしか確かめようがない。
設定の行があることが、確かめた気分を作る
設定ファイルに行がある。見た目には「設定した」。ここで安心して、応答を見ない。この形は、当サイトのブログでも書いた。PHPの修正を入れても、版の番号も「作った日」も入れ替える前と同じ文字だった ── 修正が入ったかを値で確かめる4つの方法と、3本目の知らせ（CVE-2026-115560）を当サイトで確かめた記録は、表示された版の文字は前と同じなのに、修正で増えた設定の値とファイルの md5 で比べると違いが見えた、という記録である。SameSiteでも同じで、「設定にある」は、「動いている」の証拠にならない。
属性が無いと、ログインは普通に動いてしまう
SameSiteが付いていなくても、Chromeでは、属性の無いCookieがLaxとして扱われるので、ログインは普通に動く。筆者の読みでは、設定の漏れが、静かに既定の扱いへ倒れるので、画面を見ているだけでは、漏れにも、置き換えにも気づけない。
03 用語 — 「サイト」「トップレベルの移動」「安全なメソッド」を先にそろえる
SameSiteの説明には、似た言葉が並ぶ。意味をそろえておくと、05章のチェックリストを、制作会社や提供元に伝えるときに迷わない。
サイトとオリジン
用語
サイトは、ドメインの末尾の部分と、その直前の部分を合わせたものをいう。web.devは、www.web.devはweb.devというサイトの一部で、your-project.github.ioとmy-project.github.ioは別のサイトだ、と書いている。
MDNのクッキーの解説は、サイトをまたぐ要求を、「サイト（登録されたドメイン）やスキーム（httpかhttps）が、利用者がいま見ているサイトと合わない要求」と説明している。wwwとstaticのようにサブドメインが違っても、同じサイトの要求になる。httpとhttpsのようにスキームが違うと、別のサイトの要求になる。
トップレベルの移動と、安全なメソッド
用語
トップレベルの移動は、ブラウザのアドレス欄のURLが変わる移動をいう。リンクをたどる、フォームを送る、スクリプトで表示中のアドレスを書き換える、が当たる。iframeの中の移動や、画像の読み込み、fetchは、当たらない。安全なメソッドは、GETなどの「状態を変えない要求」のことで、MDNはPOST・PUT・DELETEを含めていない。
セッションCookieとCSRF
ログインの状態を保つCookieを、ここではセッションCookieと呼ぶ。これが他のサイトから出た偽の要求にも付くと、利用者が知らない間に操作が行われうる。OWASPは、この攻撃（CSRF）をこう定義している。
"A Cross-Site Request Forgery (CSRF) attack occurs when a malicious web site, email, blog, instant message, or program tricks an authenticated user's web browser into performing an unwanted action on a trusted site."
（日本語訳: クロスサイト・リクエスト・フォージェリ（CSRF）の攻撃は、悪意のあるサイト、メール、ブログ、メッセージ、プログラムが、ログイン済みの利用者のブラウザをだまして、信頼されたサイトで望まない操作をさせるときに起きる。）
SameSiteは、他のサイトからの要求にCookieを付けないことで効く。ただし、これだけで守りきるものではない。
04 型別 — 当てはまるサイト、この記事が確かめていないこと、確かめる手順
適用範囲 — Cookieでログインを持つサイト
この記事は、ログインや会員画面、管理画面を持ち、その状態をCookieで保っているサイトを対象にしている。記事を見せるだけのサイトでは、セッションのCookieが出ないこともある。
外部のサービスをまたぐ流れがあるサイトには、注意がある。MDNは、他のサイトに埋め込まれる部品では、NoneとSecureを付ける例を書いている。web.devも、埋め込み、広告、複数のサイトにまたがるログインでは、Noneを使うように書いている。Noneが必要な流れが1つでもあるサイトは、10番目の項目で別に確かめる。
この記事が確かめていないこと
注意
次のことは、この記事では確かめていない。(1) MDNのブラウザ互換表は、JavaScriptが動かないと読めず、筆者は表を読めなかった。ブラウザごとの既定の扱いは、OWASPの記述だけに頼っている。(2) Chromiumの告知は2021年3月が最後の更新で、現在のChromeの挙動を、筆者はブラウザで確かめていない。(3) SameSiteが無い、または置き換えられたことで、実際の攻撃が成り立つかは、確かめていない。 (4) 当サイトでも、複数のブラウザでの挙動の違いは測っていない。07章に書くのは、応答のSet-Cookieにそのとき属性が付いていたか、までである。
確かめ方は、3段に分けられる
確かめ方は3段に分けられる。1段目は設定ファイルの行を読む。手軽だが、書いてあるだけで効いたかは分からない。2段目は、動いている設定の値を取り出して読む。置き換えが見えることがある。3段目は、外から応答を取り、Set-Cookieのヘッダーを読む。ブラウザが受け取る実物なので、決め手になる。下の手順は3段目が中心である。
確かめる手順1 — ログインの入口を3つまで決める
ログイン画面、会員画面、管理画面のうち、Cookieでログインの状態を保っているものを、3つまで書き出す。入口が10個あっても、最初は3つでよい。
確かめる手順2 — 応答のヘッダーを取り、Set-Cookieの行を読む
ブラウザを使わなくても、1行で応答のヘッダーを取れる。次の形は、自分のログイン画面のアドレスに変えて使う。
curl -s -D - -o /dev/null https://example.com/login出力の中の、Set-Cookieで始まる行を探す。1つのCookieにつき1行あり、行の末尾にSecure、HttpOnly、SameSite=Laxのような語が並ぶ。ログインの前にCookieが出るサイトもあれば、ログインの後で初めて出るサイトもある。出ない場合は、ブラウザの開発者ツールを使う（手順5）。
実務のヒント
Cookieの値の部分は、メール・チャット・チケットに貼らない。値は、ログイン状態そのものである。共有するときは、名前と属性だけを書き、値の部分は「…」に置き換える。
確かめる手順3 — Secure・HttpOnly・SameSiteを○×で書く
Set-Cookieの行ごとに、3つの属性があるかを、○と×で書く。SameSiteは、値も書き留める。たとえば「ログインのCookie: Secure ○、HttpOnly ○、SameSite ×」のようにする。この表が、直す前の姿になる。SameSiteが×でも、Chromeでは動くので、急に壊れるわけではない。それでも、「意図して付けなかった」のか「付けたつもりが付いていなかった」のかは、区別しておく。
確かめる手順4 — 設定と応答を並べる
設定ファイルにSameSiteを書いた行があって、応答に出ていなければ、どこかで置き換えられている。行が無くて、応答にも出ていなければ、単に書いていないだけである。前者は置き換える側を探し、後者は書けばよい。設定を自分で読めないときは、制作会社や提供元に聞く（チェックリストの7番目）。
確かめる手順5 — ブラウザの開発者ツールで見る
curlで見つからないときや、ログイン後の状態を見たいときは、ブラウザの開発者ツールを使う。Chrome DevToolsのCookieのページには、Cookiesの表にSameSiteの欄があると書かれている。ただし、そのページの書き方は古いので、Noneの表示は実際の画面で確かめる。
確かめる手順6 — 直したら、同じ見方で応答を見る
直したあとは、設定ファイルの行を読み直すのではなく、手順2と同じ形で応答を取り直す。直す前と同じ見方で、直した後を見るのが肝心である。大きさやエラーの記録も一緒に確かめる。ページの違いを自動で比べるツールもあるが、Set-Cookieまで比べるかは、確かめていない。
05 明日、担当サイトで確認できること
担当サイトのログインのCookieを、応答で確かめるための13項目である。1〜5番目は応答を取る手順、6〜7番目は設定ファイルと制作会社への確かめ方、8番目は属性の付いていないCookieの控え方、9番目は共有の仕方、10番目は外部サービス、11番目はブラウザでの確認、12〜13番目は直したあとの確かめである。1項目は5分以内でできる。チェックの状態は、お使いのブラウザに保存され、サーバーには送られない。
- ログイン画面・会員画面・管理画面のうち、Cookieでログインの状態を保つものを、3つまで書き出す
- 1つ目の入口のアドレスで、curlなどで応答のヘッダーを取り、Set-Cookieで始まる行の数を数える
- Set-Cookieの行ごとに、Secure・HttpOnly・SameSiteの3つがあるかを、○か×で書く
- SameSiteが付いている行は、値がLax・Strict・Noneのどれかを、1語で書き留める
- ログインする前と、ログインした後の2回分の応答で、同じ見方をして、結果を並べて書く
- 設定ファイルにSameSiteを書いた行があるかを1回探し、あれば応答と食い違わないかを比べる
- 担当の制作会社か提供元に、セッションの設定を後から作り直す部品がないかを、1通で聞く
- SameSiteの付いていないCookieがあれば、名前だけを控え、ログイン用かどうかを分けて書く
- 共有用の記録に貼るときは、Cookieの値の部分を「…」に置き換えてから貼る
- 外部サービスをまたぐログインや埋め込みが1つでもあるかを書き、あれば、Noneが必要かを提供元の文書で確かめる
- ブラウザの開発者ツールのApplicationを開き、CookiesのSameSiteの列の値を1つ読んで、curlの結果と比べる
- 直すときは、試験用のサイトで先に直し、5ページ分の大きさとエラーの記録が前と同じかを比べる
- 直した後に、同じ手順で応答をもう一度取り、日付と結果を1行で記録に残す
終わったら、SameSiteが付いていないCookieの名前と、置き換える部品の有無を、日付と一緒に1枚に残しておくと、部品や設定を更新したあとの変化に気づける。
06 代替・他の選択肢 — 確かめ方と、SameSiteだけに頼らない守り方
確かめ方を比べる
応答を確かめる方法は、curl以外にもある。次の表は、筆者の整理で、手間の欄は筆者の読みである。
| 方法 | 分かること | 分からないこと | 手間（筆者の読み） |
|---|---|---|---|
| 設定ファイルを読む | 書いた行があるか | 効いたか。後から置き換えられたか | 小さい |
| 動いている設定の値を取り出す | 実行中の値。置き換えが見えることがある | ブラウザへ届く応答そのもの | 中くらい（サーバーに入る権限が要ることがある） |
| curlで応答のヘッダーを取る | Set-Cookieに出た属性。外から取れる | ログイン後だけ出るCookie。ブラウザでの扱い | 小さい |
| ブラウザの開発者ツールで見る | ログイン後を含む、実際のCookieの属性 | 他のブラウザでの扱い | 小さい |
| 診断ツールにかける | ツールの診断項目に挙がっているもの | ツールの項目に無いもの | 小さい |
診断ツールの説明に、Cookieの属性が挙がっているとは限らない。当サイトの🔧 【SEO/UX】WEBサイト総合分析・レポートツール — セキュリティヘッダー（HSTS・CSP・X-Frame-Options）などを診断するの説明には、Cookieの属性は挙がっていない。もう1つの🔧 【セキュリティ】WEBサイトの 外からできるセキュリティ対策監査ツール★ミエルン — 外部からご自身の管理サイトの情報を収集し、セキュリティリスクを評価・監査して具体的な対策を提示する（利用には無料の会員登録が必要です）の説明にも、Cookieの属性を調べるとは書かれていない。診断項目にCookieの属性が無いなら、SameSiteは自分で応答を見て確かめる。
SameSiteの値の選び方
値の選び方は、Cookieの役割で決まる。web.devは、次のように書いている。
"We recommend using SameSite in this way, setting cookies that affect website display to Lax, and cookies related to user actions to Strict."
（日本語訳: 次のようにSameSiteを使うことを勧める。サイトの表示に影響するCookieはLaxに、利用者の操作に関わるCookieはStrictにする。）
MDNは、Strictはログインやカートのような、いつもCookieが必要な機能に向き、Laxは、他のサイトのリンクから来たときにも表示を変えたいCookieに向く、と書いている。筆者の読みでは、ログインのCookieをStrictにすると、メールやSNSのリンクから開いたとき、ログイン済みの画面が出ないことがある。どちらを選ぶかは、サイトごとに試して決める。
SameSiteだけに頼らない
SameSiteを付けても、サイトをまたぐ偽の要求への守りが、それで終わるわけではない。OWASPは、こう書く。
"SameSite is useful as a defense-in-depth control but it does not replace a proper CSRF defense in most deployments."
（日本語訳: SameSiteは、多層防御の1つとして役に立つが、多くの構成では、CSRFへの本来の対策の代わりにはならない。）
RFCの草案も同じ趣旨で、Laxの強制は"reasonable defense in depth"（日本語訳: ある程度の多層防御）を与えるが、"does not offer a robust defense against CSRF as a general category of attack"（日本語訳: CSRF全般には、強い防御を与えない）と書く。草案は、CSRFトークンなど通常のサーバー側の対策を導入することも、強く勧めている。OWASPは、Laxが止めるのは安全でないメソッドだけで、GETで状態を変える操作があれば止まらない、とも注意している。
直すときの選択肢
置き換えが見つかったとき、直し方は部品の持ち主で決まる。(1) 置き換える側の部品がSameSiteを指定できるなら、そこで指定する。(2) 指定の場所が無いなら、置き換えのあとに値を戻す処理を、サイトの側に足す。(3) 応答のヘッダーを、サーバーの共通の設定で書き換える。(3)は影響範囲が広いので、試験用のサイトで応答を見てから決める。どの選択肢も、直した後に応答を見て、はじめて成功と呼べる。
2分間の例外にあたる「Lax-allowing-unsafe」について、仕様の草案は、一時的で、移行を助けるための措置とみなすべきだと書いており、例外に頼ったログインの流れは、いずれ壊れうる。
07 当サイトで確かめたこと — 設定に書いたSameSiteは、応答に出ていなかった
当サイトのログインのCookieを、2026年11月7日に、外から取った応答のSet-Cookieで見た。直す前の応答では、SecureとHttpOnlyは付いていたが、SameSiteが無かった。画面を見ているだけでは、付いていないことは分からない。
設定には、書いてあった
当サイトの設定ファイルには、SameSite=Laxを書いた行があった。それなのに、応答に出ていない。調べると、後から読まれる部品が、セッションの設定をまとめて置き換えていて、書いた行は効いていなかった。さらに、応答に出ていたCookieの名前も、設定に書いた名前とは違っていた。02章で書いた「設定の行がある」と「動いている」の食い違いが、そのまま起きていた。
試験用のサイトで直し、1回目は失敗した
直す作業は、まず試験用のサイトで行った。1回目は、書き方を誤った。設定の名前に含まれる「.」が、設定を書く仕組みの中で、階層の区切りとして読まれた。その結果、試験用のサイトの全ページが、同じエラーの画面になった。約1分で元に戻し、書き方を直した。2回目で通り、応答にSameSite=Laxが付いた。直したあとの確認は、5ページの大きさが前と同じであること、エラーの記録が0件であること、の2つだった。
本番にも出した（2026年11月7日 11:23）
本番に出す前に、試験用のサイトで、会員のログインと管理画面のログインを確かめた。試験用のサイトの会員のデータは古い写しのままで、直す前でもログインが通らなかったため、パスワードを再設定してから確かめた。そのうえで、本番にも同じ直しを出した。
本番では、直す前と後に、9ページの応答を取って比べた。応答の状態、大きさ、見出しの数、リンクの数、画像の数、構造化データ、PHPのエラー表示は、前後で同じだった。トップページの大きさだけ1バイト違ったが、時計の表示の差である。応答のSet-Cookieには、SameSite=Laxが付いた。また、本番のログインのCookieの名前に、でたらめなセッションの番号を付けて要求すると、直した後は新しい番号が返ってくるようになった。直す前は返ってこなかったので、筆者の読みでは、知らない番号をそのまま受け入れていた。エラーの記録は0件だった。
この確かめは、HTMLを取って数で比べたもので、ブラウザの画面を開いて確かめたものではない。05章の13番目の項目に当たる、「直した後に、日付と結果を1行で記録に残す」ことも、当サイトでは行った。
実務のヒント
当サイトの経験から言えるのは、次の3つにとどまる。(1) 「書いた設定」と「応答に出た属性」は別で、確かめるのは応答である。(2) 直す前に、試験用のサイトで先に直す。1回目の失敗が、試験用で済んだ。(3) 直す前と後で、同じ見方（応答の取り方、ページの数）を使う。本番でも同じ見方で比べた。ブラウザごとの挙動の違いや、攻撃が成り立つかは、当サイトでは確かめていない。
08 このテーマは、ここまで — 「設定を書いた」から「応答で確かめた」へ、どう積み上げてきたか
筆者の読みでは、SameSiteは、ブラウザ側の変更が先に進み、サイト側の確かめが後から付いてきた属性である。Chromiumの告知には、その経過が日付つきで残っている。2020年2月に安定版で展開が始まり、4月3日にいったん元へ戻され、7月14日に再開された。8月11日には、対象を安定版80以上の利用者の100%に広げ、実際に新しい挙動になる割合は、100%に向けて徐々に上がっていった。2021年3月18日の項目では、Chrome 91でフラグが取り除かれ、挙動が既定で有効になったと書かれている。
サイト側の確かめを、積み上げる
当サイトのブログは、公開した日に、記事のチェック項目を自分のサイトへ当てる、という形の確かめを書いてきた。記事に書いた弱点が、自分のサイトにあった ── 公開した日にチェック項目を当てたら、エラー画面の返し方と、サイトの名前の書き方がそろっていなかったは、書いた弱点が当サイトにもあった、という話だった。この記事のSameSiteも、同じ形をたどった。
「上書き」の別の例
設定が上から下へ受け継がれ、下で変えられる形は、別の場面にもある。Search Consoleの生成AIコントロールは、親プロパティの設定を子が引き継ぎ、子が上書きできる ── 自社のプロパティごとの設定と継承を書き出して確認する13項目（2026年10月時点）は、その例である。
これから確かめること
SameSiteの仕様は、草案のまま先へ進む。標準になったとき、またはブラウザの既定が変わったときは、この記事の項目も見直す。
現在の貴方のIPアドレス
このサイトで書いている人
