サードパーティが提供するクロスオリジンリソースには、多くの場合、適切な CORP ヘッダーが含まれていません。認証情報なしでリクエストできる場合は、そのようにマークすることでクロスオリジン分離を有効にできるようになりました。
新しいクロスオリジン エンベディング ポリシー(COEP)値 credentialless
をリリースしました。これにより、ブラウザは、Cookie などの認証情報なしでリクエストを送信することで、クロスオリジン リソース ポリシー(CORP)を使用しないクロスオリジン リソースを読み込むことができます。これにより、デベロッパーはクロスオリジン分離をより簡単に導入できます。
クロスオリジン分離が必要な理由
一部のウェブ API では、Spectre などのサイドチャネル攻撃のリスクが高まります。このリスクを軽減するため、ブラウザにはクロスオリジン分離と呼ばれる、オプトイン ベースの隔離環境が用意されています。クロスオリジン分離状態では、ウェブページで SharedArrayBuffer
、performance.measureUserAgentSpecificMemory()
、高解像度の高精度タイマーなどの特権機能を使用できると同時に、オプトインされていない限りオリジンを他から分離できます。
クロスオリジン分離を有効にするには、ウェブページで次の 2 つの HTTP ヘッダーを送信する必要があります。
Cross-Origin-Embedder-Policy: require-corp
Cross-Origin-Opener-Policy: same-origin
クロスオリジン分離状態では、すべてのクロスオリジン リソースが CORS で提供されるか、Cross-Origin-Resource-Policy
ヘッダーが読み込まれるように設定する必要があります。
クロスオリジン分離を有効にする際の課題
クロスオリジン分離により、ウェブページのセキュリティが向上し、強力な機能を有効にすることができます。ただし、そのデプロイは難しい場合があります。最大の課題の 1 つは、すべてのクロスオリジン リソースで CORS または CORP を有効にする必要があることです。これらのヘッダーがないリソースは、クロスオリジン分離ページでブラウザによって読み込まれません。
これらのクロスオリジン リソースは通常、サードパーティによって提供されています。サードパーティは、必要なヘッダーを追加するのが難しい場合があります。
しかし、リソースが読み込みに十分安全であることがわかっていれば、どうでしょうか。実際、リスクにさらされているリソースは、認証情報を使用してリクエストされたリソースのみです。これは、攻撃者が自分で読み込めない機密情報が含まれている可能性があるためです。つまり、認証情報なしでリクエストできるリソースは一般公開されていて、安全に読み込めます。
credentialless
で助けてください
そこで役立つのが COEP: credentialless
です。credentialless
は、Cross-Origin-Embedder-Policy
ヘッダーの新しい値です。require-corp
と同様にクロスオリジン分離を有効にできますが、Cors のないクロスオリジン リクエストには CORP:cross-origin
ヘッダーを必須とする代わりに、認証情報(Cookie など)なしで送信されます。
次の 2 つのヘッダーを使用して、クロスオリジン分離を有効にすることもできます。
Cross-Origin-Embedder-Policy: credentialless
Cross-Origin-Opener-Policy: same-origin
つまり、リクエストされたクロスオリジン サーバーは機密性の高いリソースで応答できず、リクエスト元は常に、レスポンスに一般公開されている情報のみが含まれていると想定できます。
これは、サードパーティ Cookie の段階的廃止に関する各ブラウザの計画とも合致しています。
デモ
このデモでは、さまざまなヘッダー オプションを試すことができます。 https://cross-origin-isolation.glitch.me
よくある質問
credentialless
環境で認証リクエストを送信できますか?
もちろん、リクエストのモードを変更してレスポンスの CORS チェックを必須にするという代償は伴います。<audio>
、<img>
、<link>
、<script>
、<video>
などの HTML タグの場合は、crossorigin="use-credentials"
を明示的に追加して、認証されたリクエストを送信するようにブラウザに通知します。
たとえば、https://www.example.com
のドキュメントに Cross-Origin-Embedder-Policy: credentialless
ヘッダーがある場合でも、<img
src="https://images.example.com/avatar.png" crossorigin="use-credentials">
は認証済みリクエストを送信します。
fetch()
API の場合は、request.mode = 'cors'
を使用できます。
COEP: credentialless
を提供しましたが、COEP: require-corp
はウェブサイトにとってどのように役立っていますか?
COEP: require-corp
では、一部のクロスオリジン サブリソースで Cookie が必要な場合、手動でリクエスト モードを CORS に切り替える必要はありません。
credentialless
環境で、特別なヘッダーなしでクロスオリジンの iframe を読み込むことはできますか?
いいえ。credentialless
環境でクロスオリジンの iframe を読み込むには、引き続き require-corp
と同じ条件が必要です。iframe ドキュメントは、次の 2 つのヘッダーで配信する必要があります。
Cross-Origin-Embedder-Policy: credentialless
(またはrequire-corp
)Cross-Origin-Resource-Policy: cross-origin
幸いなことに、iframe に crossorigin="anonymous"
を指定して、これらのヘッダーなしでクロスオリジンの iframe を読み込むことができるようにすることに関する議論が進行中です。
これにより、ヘッダーなしで認証情報なしでクロスオリジンの iframe を読み込むことができます。
この機能は他のブラウザにも導入されますか?
- Firefox のトラッキングに関する問題
- Webkit の位置リクエスト: 信号なし
- W3C TAG 位置情報のリクエスト: 保留中
今後の予定
クロスオリジン分離に関連するその他の課題を軽減するために、次の 2 つの更新が予定されています。
上記の障害のために Chrome オリジン トライアルに登録して SharedArrayBuffer の変更を拡張する場合は、この機能がいつ終了するのか疑問に思われるかもしれません。Chrome 96 で終了することを当初発表していましたが、Chrome 106 に延期することにしました。
リソース
- COOP と COEP を使用してウェブサイトを「クロスオリジン分離」にする
- 高度な機能のために「クロスオリジン分離」が必要な理由
- クロスオリジン分離を実現するためのガイド
- Android Chrome 88 とパソコン版 Chrome 92 での SharedArrayBuffer の更新
写真撮影: Martin Adams、Unsplash