サイトの安全性を保ち、最も重要な情報をすばやく参照できるヘッダーについて、詳細をご覧ください。
この記事では、ウェブサイトを保護するために使用できる最も重要なセキュリティ ヘッダーについて説明します。ウェブベースのセキュリティ機能について理解し、ウェブサイトへの実装方法を理解するのに役立ちます。また、リマインダーが必要になったときの参考にもなります。
- ユーザーの機密情報を扱うウェブサイトに推奨されるセキュリティ ヘッダー:
- コンテンツ セキュリティ ポリシー（CSP）
- Trusted Types
- すべてのウェブサイトで推奨されるセキュリティ ヘッダー:
- X-Content-Type-Options
- X-Frame-Options
- クロスオリジン リソース ポリシー（CORP）
- クロスオリジン オープナー ポリシー（COOP）
- HTTP Strict Transport Security（HSTS）
- 高度な機能を持つウェブサイトのセキュリティ ヘッダー:
- クロスオリジン リソース シェアリング（CORS）
- クロスオリジン エンベダー ポリシー（COEP）
セキュリティ ヘッダーの説明に入る前に、ウェブ上の既知の脅威と、それらのセキュリティ ヘッダーを使用する理由を確認してください。
インジェクションによる脆弱性からサイトを保護する
インジェクションの脆弱性は、アプリケーションによって処理される信頼できないデータがアプリケーションの動作に影響を与える可能性があり、多くの場合、攻撃者が制御するスクリプトの実行につながる可能性があります。インジェクション バグに起因する最も一般的な脆弱性は、リフレクション XSS、ストアド XSS、DOM ベースの XSS、その他のバリアントを含む、さまざまな形式のクロスサイト スクリプティング（XSS）です。
通常、XSS 脆弱性により、攻撃者は、アプリケーションで処理されたユーザーデータや、同じウェブ送信元でホストされているその他の情報に完全にアクセスできるようになります。
従来のインジェクション対策には、自動エスケープ HTML テンプレート システムを常に使用すること、危険な JavaScript API の使用を避けること、別のドメインでファイルのアップロードをホストすることによるユーザーデータの適切な処理、ユーザーが制御する HTML をサニタイズすることが挙げられます。
- コンテンツ セキュリティ ポリシー（CSP）を使用して、アプリケーションで実行できるスクリプトを制御し、インジェクションのリスクを軽減します。
- Trusted Types を使用して、危険な JavaScript API に渡されるデータのサニタイズを適用します。
- X-Content-Type-Options を使用すると、ブラウザがウェブサイトのリソースの MIME タイプを誤って解釈し、スクリプトの実行につながるおそれがあります。
サイトを他のウェブサイトから分離する
ウェブはオープンであるため、ウェブサイト間で相互にやり取りが行われ、アプリケーションのセキュリティ基準に反する可能性があります。たとえば、予期せず認証済みリクエストを行ったり、別のアプリケーションからデータを攻撃者のドキュメントに埋め込んだりして、攻撃者がアプリケーション データを変更したり読み取ったりする可能性があるからです。
ウェブ分離を弱体化させる一般的な脆弱性には、クリックジャッキング、クロスサイト リクエスト フォージェリ（CSRF）、クロスサイト スクリプト インクルード（XSSI）、さまざまなクロスサイト漏洩などがあります。
- X-Frame-Options を使用して、悪意のあるウェブサイトによってドキュメントを埋め込まないようにします。
- クロスオリジン リソース ポリシー（CORP）を使用して、ウェブサイトのリソースがクロスオリジン ウェブサイトに含まれることを防ぎます。
- クロスオリジン オープナー ポリシー（COOP）を使用して、悪意のあるウェブサイトによるインタラクションからウェブサイトのウィンドウを保護します。
- クロスオリジン リソース シェアリング（CORS）を使用して、クロスオリジン ドキュメントからウェブサイトのリソースへのアクセスを制御します。
これらのヘッダーに興味がある場合は、Post-Spectre Web Development をご覧ください。
強力なウェブサイトを安全に構築する
Spectre は、同一オリジン ポリシーに関係なく、読み込まれたデータを同じブラウジング コンテキスト グループに配置します。読み取りは可能です。ブラウザは、「クロスオリジン分離」と呼ばれる特別な環境の背後にある脆弱性を悪用する可能性のある機能を制限します。クロスオリジン分離により、SharedArrayBuffer などの強力な機能を利用できます。
- クロスオリジン エンベディング ポリシー（COEP）と COOP を使用して、クロスオリジン分離を有効にします。
サイトへのトラフィックを暗号化する
暗号化の問題は、アプリが転送中のデータを完全に暗号化していない場合に生じ、盗聴する攻撃者にユーザーのアプリケーション操作が知られる可能性があります。
HTTPS を使用していない、混合コンテンツを使用している、Secure 属性（または __Secure 接頭辞）なしで Cookie を設定している場合、CORS 検証ロジックが緩い場合は、暗号化が不十分になることがあります。
- HTTP Strict Transport Security（HSTS）を使用して、同時に HTTPS でコンテンツを提供する。
コンテンツ セキュリティ ポリシー（CSP）
クロスサイト スクリプティング（XSS）とは、ウェブサイト上の脆弱性により、悪意のあるスクリプトが挿入されて実行される攻撃です。
Content-Security-Policy は、ページで実行できるスクリプトを制限することで、XSS 攻撃を軽減するための追加レイヤを提供します。
次のいずれかの方法を使用して、厳格な CSP を有効にすることをおすすめします。
- HTML ページをサーバーでレンダリングする場合は、ノンスベースの厳格な CSP を使用します。
- HTML を静的に提供したり、キャッシュに保存したりする必要がある場合（シングルページ アプリケーションなど）は、ハッシュベースの厳格な CSP を使用します。
使用例: ノンスベースの CSP
Content-Security-Policy:
script-src 'nonce-{RANDOM1}' 'strict-dynamic' https: 'unsafe-inline';
object-src 'none';
base-uri 'none';
推奨される使用方法
1. ノンスベースの厳格な CSP を使用する {: #nonce-based-csp}
HTML ページをサーバーでレンダリングする場合は、ノンスベースの厳格な CSP を使用します。
サーバー側のリクエストごとに新しいスクリプトのノンス値を生成し、次のヘッダーを設定します。
サーバー構成ファイル
Content-Security-Policy:
script-src 'nonce-{RANDOM1}' 'strict-dynamic' https: 'unsafe-inline';
object-src 'none';
base-uri 'none';
HTML でスクリプトを読み込むには、すべての <script> タグの nonce 属性を同じ {RANDOM1} 文字列に設定します。
index.html
<script nonce="{RANDOM1}" src="https://example.com/script1.js"></script>
<script nonce="{RANDOM1}">
// Inline scripts can be used with the <code>nonce</code> attribute.
</script>
厳格なノンスベースの CSP の例として、Google フォトがあります。DevTools を使用して使用方法を確認します。
2. ハッシュベースの厳格な CSP を使用する {: #hash-based-csp}
HTML を静的に提供したり、キャッシュしたりする必要がある場合（シングルページ アプリケーションを構築する場合など）は、ハッシュベースの厳格な CSP を使用します。
サーバー構成ファイル
Content-Security-Policy:
script-src 'sha256-{HASH1}' 'sha256-{HASH2}' 'strict-dynamic' https: 'unsafe-inline';
object-src 'none';
base-uri 'none';
HTML では、ほとんどのブラウザは外部スクリプトのハッシュ化をサポートしていないため、ハッシュベースのポリシーを適用するためにスクリプトをインライン化する必要があります。
index.html
<script> ...// your script1, inlined </script> <script> ...// your script2, inlined </script>
外部スクリプトを読み込むには、オプション B: ハッシュベースの CSP レスポンス ヘッダーの「ソースのスクリプトを動的に読み込む」をご覧ください。
CSP Evaluator は CSP を評価する優れたツールですが、厳格なノンスベースの CSP の優れた例です。DevTools を使用して使用方法を確認します。
サポートされているブラウザ
CSP に関するその他の注意事項
frame-ancestorsディレクティブは、クリックジャッキングからサイトを保護します。クリックジャッキングは、信頼できないサイトによる埋め込みを許可した場合に発生するリスクです。より簡単なソリューションが必要な場合は、X-Frame-Optionsを使用して読み込みをブロックできますが、frame-ancestorsを使用すると、特定のオリジンのみをエンベダーとして許可する高度な構成が可能です。- サイトのすべてのリソースが HTTPS で読み込まれるように CSP を使用しているかもしれません。しかし最近では、ほとんどのブラウザが混合コンテンツをブロックしています。
- CSP をレポート専用モードで設定することもできます。
- CSP をサーバーサイドのヘッダーとして設定できない場合は、メタタグとしても設定できます。なお、メタタグにはレポート専用モードを使用できません（ただし、変更される可能性があります）。
詳細
Trusted Types
DOM ベースの XSS は、eval() や .innerHTML などの動的なコード実行をサポートするシンクに悪意のあるデータが渡される攻撃です。
Trusted Types は、DOM XSS のないアプリケーションの作成、セキュリティ レビュー、メンテナンスのためのツールを提供します。CSP で有効にできます。また、危険なウェブ API が特別なオブジェクト（Trusted Type）のみを受け入れるように制限することで、デフォルトで JavaScript コードを保護できます。
これらのオブジェクトを作成するには、セキュリティ ポリシーを定義して、データが DOM に書き込まれる前にセキュリティ ルール（エスケープやサニタイズなど）が一貫して適用されるようにできます。DOM XSS を導入する可能性のあるコード内の場所は これらのポリシーだけです
使用例
Content-Security-Policy: require-trusted-types-for 'script'
// Feature detection
if (window.trustedTypes && trustedTypes.createPolicy) {
// Name and create a policy
const policy = trustedTypes.createPolicy('escapePolicy', {
createHTML: str => {
return str.replace(/\</g, '<').replace(/>/g, '>');
}
});
}
// Assignment of raw strings is blocked by Trusted Types.
el.innerHTML = 'some string'; // This throws an exception.
// Assignment of Trusted Types is accepted safely.
const escaped = policy.createHTML('<img src=x onerror=alert(1)>');
el.innerHTML = escaped; // '&lt;img src=x onerror=alert(1)&gt;'
推奨される使用方法
-
危険な DOM シンクに Trusted Types を適用する CSP と Trusted Types ヘッダー:
Content-Security-Policy: require-trusted-types-for 'script'
現在、
require-trusted-types-forディレクティブに使用できる値は'script'のみです。もちろん、Trusted Types を他の CSP ディレクティブと組み合わせることもできます。
上記のノンスベースの CSP を Trusted Types と統合します。
Content-Security-Policy:
script-src 'nonce-{RANDOM1}' 'strict-dynamic' https: 'unsafe-inline';
object-src 'none';
base-uri 'none';
require-trusted-types-for 'script';
<aside class="note"><b>注: </b>追加の <code>trusted-types</code> ディレクティブ（<code>trusted-types myPolicy</code> など）を設定することで、許可される Trusted Types ポリシー名を制限できます。ただし、これは必須ではありません。</aside>
-
ポリシーを定義する
ポリシー:
// Feature detection
if (window.trustedTypes && trustedTypes.createPolicy) {
// Name and create a policy
const policy = trustedTypes.createPolicy('escapePolicy', {
createHTML: str => {
return str.replace(/\/g, '>');
}
});
}
-
ポリシーを適用
DOM にデータを書き込む場合はこのポリシーを使用します。
// Assignment of raw strings are blocked by Trusted Types.
el.innerHTML = 'some string'; // This throws an exception.</p>
<p>// Assignment of Trusted Types is accepted safely.
const escaped = policy.createHTML('<img src="x" onerror="alert(1)">');
el.innerHTML = escaped; // '<img src=x onerror=alert(1)>'
require-trusted-types-for 'script' では、信頼できるタイプを使用する必要があります。危険な DOM API を文字列とともに使用すると、エラーが発生します。
サポートされているブラウザ
詳細
- Trusted Types で DOM ベースのクロスサイト スクリプティングの脆弱性を防止する
- CSP: require-trusted-types-for - HTTP |
MDN
- CSP: trust-types - HTTP | MDN
- Trusted Types のデモ - DevTools Inspector を開いて、状況を確認します。
X-Content-Type-Options
悪意のある HTML ドキュメントがドメインから提供される場合（たとえば、写真サービスにアップロードされた画像に有効な HTML マークアップが含まれている場合）、一部のブラウザではアクティブなドキュメントとして扱われ、アプリケーションのコンテキストでスクリプトを実行できるため、クロスサイト スクリプティングのバグが発生します。
X-Content-Type-Options: nosniff は、特定のレスポンスの Content-Type ヘッダーに設定されている MIME タイプが正しいことをブラウザに通知することで、これを防ぎます。このヘッダーは、すべてのリソースに使用することをおすすめします。
使用例
X-Content-Type-Options: nosniff
推奨される使用方法
サーバーから提供されるすべてのリソースで、適切な Content-Type ヘッダーとともに X-Content-Type-Options: nosniff を指定することをおすすめします。
ドキュメントの HTML とともに送信されるヘッダーの例
X-Content-Type-Options: nosniff Content-Type: text/html; charset=utf-8
サポートされているブラウザ
詳細
X フレーム オプション
悪意のあるウェブサイトにサイトが iframe として埋め込まれている場合、攻撃者はクリックジャッキングを使用して、意図しない操作を実行するおそれがあります。また、場合によっては、Spectre 型攻撃によって、悪意のあるウェブサイトに埋め込みドキュメントの内容を知る機会が与えられます。
X-Frame-Options は、ブラウザに <frame>、<iframe>、<embed>、<object> のページのレンダリングを許可するかどうかを示します。すべてのドキュメントでこのヘッダーを送信して、他のドキュメントによる埋め込みが許可されているかどうかを示すことをおすすめします。
使用例
X-Frame-Options: DENY
推奨される使用方法
埋め込みを想定していないドキュメントでは、X-Frame-Options ヘッダーを使用する必要があります。
次の構成が iframe の読み込みにどのように影響するかについては、こちらのデモをご覧ください。X-Frame-Options プルダウン メニューを変更し、[iframe を再読み込み] ボタンをクリックします。
お客様のウェブサイトを他のウェブサイトに埋め込まないように保護します
他のドキュメントによる埋め込みを拒否します。
X-Frame-Options: DENY
クロスオリジン ウェブサイトによる埋め込みからウェブサイトを保護
同一オリジンのドキュメントにのみ埋め込みを許可。
X-Frame-Options: SAMEORIGIN
サポートされているブラウザ
詳細
クロスオリジン リソース ポリシー（CORP）
攻撃者は、別のオリジン（自分のサイトなど）からリソースを埋め込み、ウェブベースのクロスサイト漏洩を悪用してリソースに関する情報を取得することがあります。
Cross-Origin-Resource-Policy は、読み込み可能なウェブサイトのセットを示すことで、このリスクを軽減します。ヘッダーは、same-origin、same-site、cross-origin の 3 つの値のいずれかを取ります。すべてのリソースでこのヘッダーを送信して、他のウェブサイトによる読み込みが許可されているかどうかを示すことをおすすめします。
使用例
Cross-Origin-Resource-Policy: same-origin
推奨される使用方法
次の 3 つのヘッダーのいずれかを付けてすべてのリソースを提供することをおすすめします。
このデモでは、Cross-Origin-Embedder-Policy: require-corp 環境でのリソースの読み込みに次の構成がどのように影響するかを試すことができます。[Cross-Origin-Resource-Policy] プルダウン メニューを変更し、[iframe を再読み込み] または [画像を再読み込み] ボタンをクリックして、影響を確認します。
リソースの読み込みを許可する cross-origin
CDN のようなサービスでは、リソースに cross-origin を適用することを推奨します（通常はクロスオリジン ページで読み込まれるため）。ただし、同様の効果を持つ CORS を介してすでに提供されている場合を除きます。
Cross-Origin-Resource-Policy: cross-origin
same-origin から読み込むリソースを制限する
same-origin は、同一オリジン ページでのみ読み込まれるリソースに適用します。これは、ユーザーに関する機密情報を含むリソースや、同じオリジンからのみ呼び出される API のレスポンスに適用する必要があります。
このヘッダーを含むリソースは、たとえば新しいブラウザ ウィンドウで URL に移動するなどして直接読み込むことができます。クロスオリジン リソース ポリシーは、リソースが他のウェブサイトに埋め込まれないようにのみ保護します。
Cross-Origin-Resource-Policy: same-origin
same-site から読み込むリソースを制限する
same-site は、上記と同様のリソースで、サイトの他のサブドメインによって読み込まれるようにすることをおすすめします。
Cross-Origin-Resource-Policy: same-site
サポートされているブラウザ
詳細
クロスオリジン オープナー ポリシー（COOP）
攻撃者のウェブサイトは、別のサイトをポップアップ ウィンドウで開き、ウェブベースのクロスサイト漏洩を悪用して、そのサイトに関する情報を確認できます。場合によっては、Spectre に基づくサイドチャネル攻撃も悪用される可能性があります。
Cross-Origin-Opener-Policy ヘッダーは、window.open() で開かれたクロスオリジン ウィンドウ、または rel="noopener" なしで target="_blank" を含むリンクから開いたクロスオリジン ウィンドウから、ドキュメントを分離する方法を提供します。そのため、ドキュメントのクロスオリジン オープナーは、そのドキュメントへの参照を持たず、操作できなくなります。
使用例
Cross-Origin-Opener-Policy: same-origin-allow-popups
推奨される使用方法
次の構成がクロスオリジン ポップアップ ウィンドウとの通信にどのように影響するかについては、こちらのデモをご覧ください。 ドキュメントとポップアップ ウィンドウの両方について [Cross-Origin-Opener-Policy] プルダウン メニューを変更し、[Open a pop] ボタンをクリックしてから、[Send a postMessage] をクリックして、メッセージが実際に配信されるかどうかを確認します。
クロスオリジン ウィンドウからドキュメントを分離する
same-origin を設定すると、ドキュメントはクロスオリジンのドキュメント ウィンドウから分離されます。
Cross-Origin-Opener-Policy: same-origin
ドキュメントをクロスオリジン ウィンドウから分離し、ポップアップを許可する
same-origin-allow-popups を設定すると、ドキュメントは、same-origin または same-origin-allow-popups で COOP を設定しない限り、ポップアップ ウィンドウへの参照を保持できます。つまり、same-origin-allow-popups は、ポップアップ ウィンドウとして開いたときにドキュメントが参照されないように保護しつつ、自身のポップアップと通信できるようにします。
Cross-Origin-Opener-Policy: same-origin-allow-popups
クロスオリジン ウィンドウでのドキュメントの参照を許可する
unsafe-none がデフォルト値ですが、このドキュメントをクロスオリジン ウィンドウで開き、相互アクセスを保持できることを明示的に示すことができます。
Cross-Origin-Opener-Policy: unsafe-none
COOP と互換性のないレポート パターン
COOP が Reporting API とのウィンドウをまたいだ操作を禁止すると、レポートを受け取ることができます。
Cross-Origin-Opener-Policy: same-origin; report-to="coop"
COOP はレポート専用モードもサポートしているため、クロスオリジン ドキュメント間の通信を実際にブロックすることなくレポートを受信できます。
Cross-Origin-Opener-Policy-Report-Only: same-origin; report-to="coop"
サポートされているブラウザ
詳細
クロスオリジン リソース シェアリング（CORS）
この記事の他の項目とは異なり、クロスオリジン リソース シェアリング（CORS）はヘッダーではなく、クロスオリジン リソースへのアクセスをリクエストして許可するブラウザ メカニズムです。
ブラウザはデフォルトで同一オリジン ポリシーを適用して、ウェブページがクロスオリジン リソースにアクセスできないようにします。たとえば、クロスオリジン画像が読み込まれると、ウェブページには視覚的に表示されますが、ページ上の JavaScript は画像データにアクセスできません。リソース プロバイダは、CORS をオプトインすることで制限を緩和し、他のウェブサイトがリソースを読み取れるようにすることができます。
使用例
Access-Control-Allow-Origin: https://example.com
Access-Control-Allow-Credentials: true
CORS の構成方法を調べる前に、リクエスト タイプの違いを理解しておくと役立ちます。リクエストの詳細に応じて、リクエストはシンプル リクエストまたはプリフライト リクエストに分類されます。
シンプル リクエストの条件:
- メソッドは
GET、HEAD、またはPOSTです。 - カスタム ヘッダーには、
Accept、Accept-Language、Content-Language、Content-Typeのみが含まれます。 Content-Typeは、application/x-www-form-urlencoded、multipart/form-data、またはtext/plainです。
それ以外はすべてプリフライト リクエストに分類されます。詳細については、クロスオリジン リソース シェアリング（CORS） - HTTP | MDN をご覧ください。
推奨される使用方法
シンプルなリクエスト
リクエストがシンプル リクエストの条件を満たす場合、ブラウザはリクエスト送信元を示す Origin ヘッダーを含むクロスオリジン リクエストを送信します。
リクエスト ヘッダーの例
Get / HTTP/1.1 Origin: https://example.com
レスポンス ヘッダーの例
Access-Control-Allow-Origin: https://example.com Access-Control-Allow-Credentials: true
Access-Control-Allow-Origin: https://example.comは、https://example.comがレスポンスの内容にアクセスできることを示します。どのサイトからも読み取り可能なリソースは、このヘッダーを*に設定できます。この場合、ブラウザは認証情報なしでリクエストを行うだけで済みます。Access-Control-Allow-Credentials: trueは、認証情報（Cookie）を保持するリクエストでリソースの読み込みが許可されていることを示します。そうしないと、リクエスト元の送信元がAccess-Control-Allow-Originヘッダー内に存在していても、認証済みリクエストは拒否されます。
こちらのデモでは、Cross-Origin-Embedder-Policy: require-corp 環境でシンプルなリクエストが読み込みリソースにどのように影響するかを試すことができます。[クロスオリジン リソース シェアリング] チェックボックスをクリックし、[画像を再読み込み] ボタンをクリックして、効果を確認します。
プリフライトされたリクエスト
プリフライトされたリクエストの前に OPTIONS リクエストがあり、後続のリクエストの送信が許可されているかどうかを確認します。
リクエスト ヘッダーの例
OPTIONS / HTTP/1.1 Origin: https://example.com Access-Control-Request-Method: POST Access-Control-Request-Headers: X-PINGOTHER, Content-Type
Access-Control-Request-Method: POSTにより、POSTメソッドで次のリクエストを行うことができます。Access-Control-Request-Headers: X-PINGOTHER, Content-Typeを使用すると、リクエスト元は後続のリクエストでX-PINGOTHERおよびContent-TypeHTTP ヘッダーを設定できます。
レスポンス ヘッダーの例
Access-Control-Allow-Origin: https://example.com Access-Control-Allow-Credentials: true Access-Control-Allow-Methods: POST, GET, OPTIONS Access-Control-Allow-Headers: X-PINGOTHER, Content-Type Access-Control-Max-Age: 86400
Access-Control-Allow-Methods: POST, GET, OPTIONSは、POST、GET、OPTIONSメソッドで後続のリクエストを実行できることを示します。Access-Control-Allow-Headers: X-PINGOTHER, Content-Typeは、後続のリクエストにX-PINGOTHERヘッダーとContent-Typeヘッダーを含めることができることを示します。Access-Control-Max-Age: 86400は、プリフライトされたリクエストの結果を 86,400 秒間キャッシュに保存できることを示します。
サポートされているブラウザ
詳細
Cross-Origin Embedder ポリシー（COEP）
Spectre ベースの攻撃がクロスオリジン リソースを盗む能力を減らすため、SharedArrayBuffer や performance.measureUserAgentSpecificMemory() などの機能はデフォルトで無効になっています。
Cross-Origin-Embedder-Policy: require-corp では、ドキュメントやワーカーが画像、スクリプト、スタイルシート、iframe などのクロスオリジン リソースを読み込むことはできません。ただし、これらのリソースが CORS または CORP ヘッダーを介して明示的に読み込まれるように設定している場合を除きます。COEP を Cross-Origin-Opener-Policy と組み合わせると、ドキュメントをクロスオリジン分離にオプトインできます。
ドキュメントのクロスオリジン分離を有効にする場合は、Cross-Origin-Embedder-Policy: require-corp を使用します。
使用例
Cross-Origin-Embedder-Policy: require-corp
使用例
COEP は単一の値 require-corp を取ります。このヘッダーを送信することで、CORS または CORP を介してオプトインしないリソースの読み込みをブロックするようにブラウザに指示できます。
次の構成がリソースの読み込みにどのように影響するかについては、こちらのデモをご覧ください。[Cross-Origin-Embedder-Policy] プルダウン メニュー、[Cross-Origin-Resource-Policy] プルダウン メニュー、[Report Only] チェックボックスなどを変更して、読み込みリソースへの影響を確認します。また、レポート エンドポイントのデモを開いて、ブロックされたリソースが報告されるかどうかを確認します。
クロスオリジン分離を有効にする
Cross-Origin-Embedder-Policy: require-corp を Cross-Origin-Opener-Policy: same-origin と一緒に送信して、クロスオリジン分離を有効にします。
Cross-Origin-Embedder-Policy: require-corp Cross-Origin-Opener-Policy: same-origin
COEP と互換性のないリソースを報告する
COEP によってブロックされたリソースに関するレポートは、Reporting API を使用して受信できます。
Cross-Origin-Embedder-Policy: require-corp; report-to="coep"
COEP はレポート専用モードもサポートしているため、リソースの読み込みを実際にブロックすることなくレポートを受信できます。
Cross-Origin-Embedder-Policy-Report-Only: require-corp; report-to="coep"
サポートされているブラウザ
詳細
HTTP Strict Transport Security（HSTS）
プレーン HTTP 接続を介した通信は暗号化されないため、転送されたデータはネットワーク レベルの盗聴者にアクセスできます。
Strict-Transport-Security ヘッダーは、HTTP を使用してサイトを読み込まず、代わりに HTTPS を使用するようにブラウザに通知します。設定されると、ブラウザは HTTP ではなく HTTPS を使用して、ヘッダーで定義された期間、リダイレクトなしでドメインにアクセスします。
使用例
Strict-Transport-Security: max-age=31536000
推奨される使用方法
HTTP から HTTPS に移行するウェブサイトでは、HTTP を含むリクエストを受信したときに Strict-Transport-Security ヘッダーで応答する必要があります。
Strict-Transport-Security: max-age=31536000
サポートされているブラウザ