Cookie は、頼んだページに関係なく付いていく — ambient authority — Webセキュリティの実務

リクエストがアプリケーションに届くまで

ブラウザURL入力今ここ
DNS名前→IP
ルータ経路選択
ロードバランサ振り分け
Nginx受け口
アプリ処理今ここ
DB保存

このコースでは、ブラウザが何を強制し、何をサーバに任せているかの境目を見ます。1本目は、Cookie がどの要求に付くかを誰が決めているかです。

まず結論

ブラウザが Cookie を付けるかどうかは、送り先と Cookie の属性で決まります。要求を起こしたページが誰かは、判定の主役ではありません。自前サーバの実測では、a.test のページから送ったフォームの POST に、b.test の Cookie が付きました。

RFC 6265bis のドラフトはこの性質を ambient authority と呼び、confused deputy の名を挙げています。宛先の指定と権限の証明が別々の経路で届くことが原因だ、と仕様自身が書いています。

このコースの芯はここから始まります。ブラウザが確かめられるのは「どこから来たか」までで、「本人が望んだか」はサーバが自分で確かめるしかありません。

? 読む前に予測

b.test は `SameSite=None; Secure` の Cookie `c_none` を発行済みです。その後、別サイト a.test のページにあるフォームのボタンを押し、b.test へ POST しました。b.test のサーバログには何が残るでしょうか。

当てることが目的ではありません。外した予測ほど記憶に残るので、直感で選んでください。

抽象原理

付けるかどうかは、送り先で決まる

「状態を持たないHTTPとCookie/セッション」では、HTTP が前の要求を覚えないので、合言葉(Cookie)をクライアントが毎回運ぶ、というところまで見ました。この回で見るのは、ブラウザがどの要求にその合言葉を載せるかです。

6265bis の取り出しアルゴリズムは、こう始まります。

The user agent includes stored cookies in the Cookie HTTP request header field.

§5.8.3 が、保存済みの Cookie から載せるものを絞ります。見る材料は送り先の URL と Cookie の属性です。ドメイン・パスが送り先に合うか、Secure なら安全な接続か、HttpOnly なら HTTP 以外の API からの取り出しでないか。SameSite については次の条件で除外します。

If the cookie's same-site-flag is not "None" and the retrieval's same-site status is "cross-site", then exclude the cookie unless all of the following conditions are met:

要求を起こしたページが入り込むのは、この same-site status という1点だけです。SameSite=None の Cookie なら、どのページが要求を起こしたかは判定に効きません。

Cookie を載せるかの判定に入る材料と、入らない材料

a.test のページ要求を起こした側

利用者の意思ボタンを押したのは誰の望みか

b.test への要求になる

ブラウザの判定(§5.8.3)送り先・ドメイン・パス・Secure・SameSite

条件を満たせば付ける

b.test に届く要求Cookie: b.test の Cookie / Origin: a.test

・ページの出どころが判定に入るのは same-site status を通してだけ
・利用者の意思は、どの段の材料にもなっていない

具体実物

a.test のフォームから b.test へ

自前の node サーバ(127.0.0.1:8443)を立て、a.test と b.test の2つの名前で応答させました。/etc/hosts は書き換えず、同じプロセスの CONNECT プロキシがどの名前への接続も 127.0.0.1 に流します。ブラウザから見たホスト名は a.test / b.test のままです。

手順は2つです。b.test で SameSite=None / Lax / Strict / 属性なしの4種の Cookie を発行し(すべて Secure)、次に a.test のページのフォーム(note=hello を b.test/counter へ POST)のボタンを押します。ブラウザは Playwright 1.63.0 に同梱の Chromium 153.0.8010.12・Firefox 155.0・WebKit 26.6(headless)で、市販のブラウザではありません。 環境は macOS 26.5.2・node v24.21.0 です。

lab/out-1-chromium-1.txt より抜粋(実行結果の1行と、サーバの生ログ3行のうち POST の行。改変なし)コマンド出力

[chromium 153.0.8010.12] page a.test -> POST b.test/counter : count=2
{"t":"2026-09-24T01:55:48.375Z","method":"POST","host":"b.test:8443","path":"/counter","cookie":"c_none=exp1; c_unspec=exp1","origin":"https://a.test:8443","referer":"https://a.test:8443/","sec-fetch-site":"cross-site","sec-fetch-mode":"navigate","content-type":"application/x-www-form-urlencoded","acr-method":null,"acr-headers":null,"body":"note=hello"}

同じ行に "cookie":"c_none=exp1; c_unspec=exp1" と "origin":"https://a.test:8443" があります。ブラウザは要求の出どころを隠していません。そのうえで、送り先の Cookie を付けています。 3エンジン×2回の6回すべてで同じ結果になり、カウンタは毎回増えました。

c_lax と c_strict は6回とも付いていません。§5.8.3 がクロスサイトの取り出しから外したからです。c_unspec(属性なし)はドラフトでは same-site-flag が Default になり(§5.7)、本来は除外される側です。それでも付いた理由はエンジンで異なるので、ここでは一般化しません。

✓ ここまでの確認

実演の POST の行を見た b.test のサーバが、Cookie ヘッダから確実に言えることはどれですか。

抽象原理

指定と権限が、別々の経路で届く

6265bis はこの性質に節を1つ割いています。§8.2 Ambient Authority です。

When issuing those requests, user agents attach cookies even if the remote party does not know the contents of the cookies, potentially letting the remote party exercise authority at an unwary server.

Although this security concern goes by a number of names (e.g., cross-site request forgery, confused deputy), the issue stems from cookies being a form of ambient authority. Cookies encourage server operators to separate designation (in the form of URLs) from authorization (in the form of cookies).

何をするかの指定は URL で、してよいという証明は Cookie で届きます。 URL はどのページでも書けます。Cookie はブラウザが送り先を見て付けます。2つを組み合わせるのはサーバで、組み合わせた結果を利用者が望んだかは、どちらの経路にも入っていません。仕様はその帰結を as though they were authorized by the user と書きます。

ブラウザにできるのは、Origin のように「どこから来たか」を正直に伝えることまでです。「本人が望んだか」は、サーバが自分で確かめるしかありません。 このコースの残りは、この一文を場面ごとに確かめる作業です。

具体実物

1988年、課金ファイルを上書きしたコンパイラ

Norm Hardy の "The Confused Deputy"(ACM SIGOPS Operating Systems Review 22(4), 1988)は、著者の当時の勤め先だった時分割サービス会社で起きた出来事を書いています(about eleven years ago)。著者自身が nearly true story (inessential details have been changed) と断っており、細部は変えてあります。以下は cap-lore.com 掲載版からの引用です。

コンパイラは統計を (SYSX)STAT に書くため、自分のディレクトリに書ける home files license を持っていました。利用者はデバッグ出力の書き先を名前で指定できます。

Some user came to know the name (SYSX)BILL and supplied it to the compiler as the name of the file to receive the debugging information.

The operating system, observing that the compiler had home files license, let the compiler write debugging information over (SYSX)BILL.

課金情報は失われました。OS は権限を検査しています。検査したうえで通ったのです。Hardy の診断はこうです。

The fundamental problem is that the compiler runs with authority stemming from two sources.

Another indication of poor design is that disparate mechanisms were necessary to arrange separately that the compiler (1) know what file to write on and (2) be authorized to write on that file.

書き先の指定は利用者から、書いてよい権限はコンパイラ自身の license から。 別々の経路で届いたものを、コンパイラは区別できませんでした(It has no way to keep them apart.)。Hardy の答えは、指定と権限を1つにした capability です(The capability both identifies the file and authorizes the compiler to write there.)。

✓ ここまでの確認

Hardy が 1988 年の論文で、コンパイラが課金ファイルを上書きした根本原因として書いたのはどれですか。

⇄ 2つを見比べる

具体例 A

Web: a.test のフォームから b.test への POST

宛先の URL は a.test のページが書き、Cookie はブラウザが送り先を見て付けました。b.test のサーバには両方がそろって届き、カウンタは増えました。Origin は a.test を示していましたが、Cookie だけを見るサーバはそれを使いません。

実測(Playwright 同梱ブラウザ、各2回)表

エンジン                  POST に付いた Cookie
Chromium 153.0.8010.12    c_none, c_unspec
Firefox 155.0             c_none, c_unspec
WebKit 26.6               c_none, c_unspec
6回とも付かなかったもの   c_lax, c_strict

具体例 B

1988: (SYSX)BILL を上書きしたコンパイラ

書き先の名前は利用者が渡し、書く権限はコンパイラ自身の home files license から来ました。OS は license を見て書き込みを許し、課金情報が失われました。

Hardy 1988 の構図表

         指定の出どころ          権限の出どころ
Web      ページが書いた URL      ブラウザが付けた Cookie
Hardy    利用者が渡したファイル名 コンパイラの license

時代も仕組みも違う2つの事故で、検査をする側(b.test のサーバ、OS)は何を見て許可したでしょうか。そこに欠けていたものは何でしょうか。

許可の判断に使われた材料が、依頼者の目的を含んでいたかを考えてください。

実務の場面エージェントが書いた『ログイン済みユーザーだけが実行できるので安全です』という説明を見る

生成された更新 API のコードに、セッション Cookie でユーザーを引き、見つからなければ 401 を返す処理だけがあり、説明に「ログイン済みユーザーだけが実行できるので安全です」とあったとします。

この処理が確かめているのは、その Cookie を持つブラウザから要求が来たことです。実測のとおり、SameSite=None の Cookie は a.test のページから起きた POST にも付きます。「ログイン済み」は「本人が望んだ」を含みません。

見るべきは2点です。Set-Cookie に SameSite が明示されているか。状態を変える処理が、Cookie 以外にページ側から作れない信号を確かめているか。防御の形はこのコースの後半で扱います。

この章のまとめ

ブラウザが Cookie を付けるかは、送り先と Cookie の属性で決まる(6265bis §5.8.3)。要求を起こしたページは same-site status を通してしか入らない。
実測(Playwright 同梱の3エンジン×2回)では、a.test からの POST に b.test の c_none と c_unspec が付き、c_lax と c_strict は付かなかった。「全部付く」でも「付かない」でもない。
6265bis §8.2 はこれを ambient authority と呼び、confused deputy の名を挙げ、指定(URL)と権限(Cookie)の分離を原因とする。
Hardy 1988 のコンパイラも、指定と権限を別経路で受け取り、区別できなかった。検査は働いていた。
ブラウザが伝えられるのは「どこから来たか」まで。「本人が望んだか」は、サーバが自分で確かめるしかない。

自分の現場で確かめる

読んだだけでは身につきません。手元の環境で実際に見てみてください。

自分の関わるサービスで、状態を変える POST の処理を1つ選び、Cookie のセッション以外に何を確かめているかをコードで追う。何も無ければ、それは「どのブラウザから来たか」しか見ていない
発行している Cookie の Set-Cookie を並べ、SameSite 属性を明示していないものが無いか確かめる。明示していないものは、エンジンごとに扱いが違う

理解度チェック

読んだ直後は「分かった」と感じやすいものです。実際に解いて確かめてください。

問題 1 / 3正解: 0

RFC 6265bis ドラフト §8.2 Ambient Authority は、Cookie のこの性質から生じる問題の呼び名として何を挙げていますか。

用語集(4語)

ambient authority: 要求する側が明示しなくても、周りの状態から自動で付いてくる権限。6265bis §8.2 は Cookie をこの一種とする。
confused deputy: 他者の依頼で動くプログラムが、依頼者の指定した対象に、自分の権限を使ってしまう事故。Hardy 1988 の題名。6265bis §8.2 と Fetch Standard もこの語を使う。
designation と authorization: 何を対象にするかの指定と、それをしてよいという権限の証明。6265bis §8.2 は、Cookie が前者を URL、後者を Cookie に分けさせると書く。
RFC 6265bis: Cookie の仕様 RFC 6265 の改訂ドラフト。版番号付きの最新は -22(2025-12-01)。2026-09-24 に閲覧した datatracker では IESG state が RFC Ed Queue で、RFC 番号は未付与。