要約

  • 2009年1月のOrigin草案は、HTTP要求を起こした側の文脈をサーバーへ伝えるヘッダーを提案した。2011年12月のRFC 6454は、その背後にある「どのページを同じ出自とみなすか」という境界を明文化した。
  • ブラウザーが数えるのは方式、ホスト、ポートである。パスは数えない。同じオリジンに置かれた外部投稿のHTMLは、そのサイトのページとブラウザー上の権限を共有し得る。

隣の部屋だと思っていた

運営者は会員ページを /account に、投稿作品を /uploads に置く。サーバーの設定では別の棚かもしれない。ブラウザーの判定は違う。URLの方式、ホスト、ポートが同じなら、両者は一つのオリジンに入る。パスの名前は境界線にならない。

2011年12月のRFC 6454は、すでにブラウザーの実務から育っていた同一オリジンの考え方を整理した。文書ごとに別の権限を与えれば、複数ページで動くアプリは小さなやり取りのたびに許可を求めることになる。オリジンはその面倒を減らすためのまとまりだ。便利なまとまりほど、何を中へ置くかが重くなる。

RFCは具体的に、利用者が持ち込んだ内容を取り上げている。信用できない文章を同じオリジンから動作するHTMLとして返せば、そのページのスクリプトはサイトのブラウザー上の権限を帯びる。サーバー側の本人確認や操作権限は別に働く。それでも /uploads という看板だけで、ブラウザーがそのHTMLを低い身分に落とすことはない。応答のメディア型も運営上の判断になる。

数えられたポート、数えられないパス

example.com のHTTPページと、同じホストでポート80を明示した別のパスは同じオリジンになる。80はHTTPの既定ポートだからだ。ポートを変えると別になる。http を https に変えても別になる。同じ名前のサーバーに見えても、暗号化されていないページの内容を攻撃者が書き換えられる可能性がある以上、HTTPS側の信頼をそのまま渡せない。RFCはこの理由を自ら説明している。

一方、/account と /uploads は同じ三要素の下に残る。運営者は投稿を別のホストへ置くか、活動できない形式で返すか、あるいは同じ権限の部屋に迎えるかを選ぶ。ブラウザーは運営組織の意図を読み取らず、実際に届いたURLと応答を処理する。

2009年1月のOrigin草案は、サーバーに届いた要求の発端を示すことに力点があった。Originヘッダーを使えば、サーバーは別サイトからの偽造要求を調べる材料を得る。これは期限付きのInternet-Draftであり、採択された標準ではなかった。RFC 6454はヘッダーの説明に加え、要求を出す前からブラウザーが使うオリジンの定義を整えた。通常の三要素を持たない出自は文字列 null になる。プライバシー上敏感な文脈からの要求についても同じ値を定めた。

のちの2014年W3C CORS勧告は、この出自を使って他サイトへ応答を読ませるかを決めた。要求が起こす操作の承認は別の仕事だと明記している。CORSの許可より手前で、ブラウザーはすでに誰を同じ部屋に入れるか決めていた。

RFC 6454が書いたのは、その部屋の間取りである。ポートは壁になり、パスは壁にならない。部屋に置く原稿の種類は、サイトが決める。