重要！ まずは「オリジン」を理解しよう：HTML5時代の「新しいセキュリティ・エチケット」（1）（2/2 ページ）

dataスキーム、fileスキーム

　http、https以外のスキームとして注意すべき点としては、dataスキームとfileスキームがあります。

　RFC6454では、dataスキームはオリジンとしてそれぞれ固有のユニークIDを持つ、と書かれていますが、実際のブラウザ上の実装では、dataスキームで示されるリソースを含む元ページと同一のオリジンを持っていると判断されることがほとんどです。

　また、fileスキームのリソースについては、複数のfileスキームのリソースについてどこまでを同一のオリジンと見なすかについては、完全にブラウザごとの実装依存となっています。

　実際に同一オリジンポリシーに基づき、各リソースのオリジンによって動作が制限される機構としては、次のようなものがあります。

XMLHttpRequest

　XMLHttpRequestによるリソースへのリクエストでは、取得しようとしているリソースのオリジンが現在表示しているドキュメントのオリジンと同一の場合には、無条件にレスポンスの内容をJavaScriptからresponseTextなどを通じて取得できます。

　オリジンが一致しない場合には、リソースの提供側が明示的に許可している場合にしか、JavaScriptからレスポンスの内容にアクセスすることはできません。

Canvas

　HTML5のCanvas要素を使用して表示された画像は、そのHTMLのオリジンと同一のオリジンに属するものであれば、表示されている内容にJavaScriptからgetImageDataメソッドなどを通じてアクセス可能です。

　オリジンが一致しない場合には、画像提供側で明示的に許可している場合にしかアクセスできません。

Web Storage

　HTML5で導入されたデータの永続的な保存機構であるWeb Storageは、保存されるデータの境界はオリジンに基づきます。保存されたデータには同一オリジン間では自由にアクセスできますが、クロスオリジンではアクセスできません。

X-Frame-Options

　クリックジャッキングを防止する機構であるX-Frame-Optionsヘッダでは、SAMEORIGINという指定をした場合には、そのコンテンツと同一オリジンを持つページからであればフレーム内で表示できます。

　オリジンが異なる場合にはフレーム内に表示できません。

オリジンではなく、独自の境界条件を定めているもの

　一方、オリジンではない独自の境界条件を定めている機構もブラウザ上には多数存在します。例えば以下のようなものです。

Cookie

　Cookieはサーバ側で発行時にpathやdomainの指定が可能であり、これらは明らかにオリジンのホストと異なる境界となります。またデフォルトではhttpとhttps両方のスキームで共有されます。

HTTP認証

　基本認証などのHTTP認証は、path名を基に認証情報を送信するなど、オリジンに基づかない動作となっています。

document.domain

　JavaScriptでdocument.domainを書き換え、複数のコンテンツ間でdocument.domainを一致させることにより、ホストを超えてinnerHTMLの読み書きなどが可能になります。

　このように、HTML5時代の新しい機能についてはオリジンという整理された概念に基づいて境界にセキュリティの条件を定めているのに対し、古くからブラウザに備わる機構ではオリジンではない条件が基準となっていることが多々あります。

　次回は、同一オリジンポリシーを破る攻撃の代表例である「クロスサイトスクリプティング」について解説したいと思います。