COEP を使用して CORP ヘッダーなしでクロスオリジン リソースを読み込む: 認証情報なし

サードパーティが提供するクロスオリジンリソースには、多くの場合、適切な CORP ヘッダーが含まれていません。認証情報なしでリクエストできる場合は、そのようにマークすることでクロスオリジン分離を有効にできるようになりました。

Eiji Kitamura

新しいクロスオリジン エンベディング ポリシー（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 を読み込むことができます。

この機能は他のブラウザにも導入されますか？

今後の予定

クロスオリジン分離に関連するその他の課題を軽減するために、次の 2 つの更新が予定されています。

上記の障害のために Chrome オリジン トライアルに登録して SharedArrayBuffer の変更を拡張する場合は、この機能がいつ終了するのか疑問に思われるかもしれません。Chrome 96 で終了することを当初発表していましたが、Chrome 106 に延期することにしました。

リソース

写真撮影: Martin Adams、Unsplash