要約

  • 2007年のW3C草案は、資源の持ち主が別サイトからの読み取りを許す方法を探った。2009年のCORS草案では、要求元のOriginと資源側の許可をブラウザーが照合する形が見えてくる。
  • 2014年の勧告は Access-Control-Allow-Origin による応答の公開条件を定めた。条件に当てはまる要求にはOPTIONSによる事前確認がある一方、単純な要求はサーバーに届いても、応答をページのプログラムが読めるとは限らない。

天気のグラフを作るページが、別サイトの観測値を欲しがる。住所は知っている。通信もできる。それでもブラウザーは、よその家に届いた返事を勝手に開けてページ内のプログラムへ渡さない。同一オリジンの境界とは、その返事を読む権利の話でもある。CORS が加えたのは、持ち主自身が例外を宣言できる仕組みだった。

2007年2月15日のW3C草案 Enabling Read Access for Web Resourcesは、HTTPヘッダーやXMLの処理命令を使って資源の作者が読み取りを認める案を示した。ホストの指定方法などはまだ試行中で、完成したCORSそのものではない。大事なのは、許可を出す主体が資源側だという発想だ。2009年3月17日のCORS作業草案になると、要求側がOriginを示し、応答側が許可を返し、ブラウザーが判定する会話がさらに具体的になる。

2014年1月16日のW3C勧告では、資源は Access-Control-Allow-Origin で読ませたいオリジンを示せる。ブラウザーは要求元と照合し、合えばページ内のプログラムへ応答を渡す。資格情報を伴わない公開資源なら * という広い指定もある。一方、資格情報を伴う要求では、該当する具体的なオリジンと Access-Control-Allow-Credentials: true が必要になる。「どなたでも」と名前入りの招待状を取り違えてはいけない。

玄関で先に確認が入る場合もある。単純な範囲を超えるメソッドやプログラムが設定したヘッダーを使うとき、ブラウザーはOPTIONSで事前確認を行い、許されるメソッドとヘッダーを尋ねる。返答を確認してから本番の要求へ進み、その結果をしばらく記憶することもある。ただし、すべてのサイト間通信が事前確認を通るわけではない。ドアベルは必要な来客にだけ鳴る。

ここで最も大切なのは、送ることと読むことの区別だ。単純な要求はサーバーへ届き、サーバーが処理してしまうことがある。それでもブラウザーは応答をプログラムに見せない場合がある。2014年の勧告も、要求やその副作用を認めることと、返ってきた表現を読むことをはっきり分ける。口座を動かす操作や個人情報を変える操作は、サーバー自身が権限を確かめなければならない。CORSヘッダーは郵便の受け渡し係であって、金庫番ではない。

W3Cの公開履歴には2007年からの草案、2014年の勧告公開のお知らせ、そしてこの文書が2020年に廃止されたことが並ぶ。この時代の中心にあった選択は明快だ。資源の持ち主が読ませる相手を決め、ブラウザーがその決定を実行する。隣家の数字は借りられる。合鍵までは渡さない。