セキュリティ ヘッダーのクイック リファレンス

サイトの安全性を維持し、最も重要な詳細情報をすばやく確認できるヘッダーについてご確認ください。

Eiji Kitamura
Artur Janc
Artur Janc
X GitHub
Maud Nalpas

この記事では、ウェブサイトの保護に使用できる最も重要なセキュリティ ヘッダーについて説明します。ウェブベースのセキュリティ機能の理解、ウェブサイトへの実装方法の学習、リマインダーが必要な場合の参照としてご活用ください。

ユーザーデータを扱うウェブサイトに推奨されるセキュリティ ヘッダー:
コンテンツ セキュリティ ポリシー（CSP）
Trusted Types
すべてのウェブサイトに推奨されるセキュリティ ヘッダー:
X-Content-Type-Options
X-Frame-Options
Cross-Origin Resource Policy（CORP）
Cross-Origin Opener Policy（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）、さまざまなクロスサイト リークなどがあります。

これらのヘッダーに関心がある場合は、Post-Spectre Web Development を読むことをおすすめします。

強力なウェブサイトを安全に構築する

Spectre は、同一オリジン ポリシーにもかかわらず、同じブラウジング コンテキスト グループに読み込まれたデータを読み取り可能にします。ブラウザは、「クロスオリジン分離」と呼ばれる特別な環境の背後にある脆弱性を悪用する可能性のある機能を制限します。クロスオリジン分離を使用すると、SharedArrayBuffer などの強力な機能を使用できます。

サイトへのトラフィックを暗号化する

暗号化の問題は、アプリケーションが転送中のデータを完全に暗号化していない場合に発生します。これにより、盗聴攻撃者がユーザーとアプリケーションのやり取りを把握できるようになります。

暗号化が不十分になるのは、HTTPS を使用していない場合、混合コンテンツの場合、Secure 属性（または __Secure 接頭辞）なしで Cookie を設定している場合、CORS 検証ロジックが緩い場合などです。

コンテンツ セキュリティ ポリシー（CSP）

クロスサイト スクリプティング（XSS）は、ウェブサイトの脆弱性を利用して悪意のあるスクリプトを挿入し、実行する攻撃です。

Content-Security-Policy は、ページで実行できるスクリプトを制限することで、XSS 攻撃を軽減する追加のレイヤを提供します。

次のいずれかの方法で厳格な CSP を有効にすることをおすすめします。

  • サーバーで HTML ページをレンダリングする場合は、ノンスベースの厳格な CSP を使用します。
  • HTML を静的に配信またはキャッシュに保存する必要がある場合（シングルページ アプリケーションの場合など）は、ハッシュベースの厳格な CSP を使用します。

使用例: nonce ベースの CSP

Content-Security-Policy:
  script-src 'nonce-{RANDOM1}' 'strict-dynamic' https: 'unsafe-inline';
  object-src 'none';
  base-uri 'none';
CSP の使用方法

1. ノンスベースの厳格な CSP を使用する {: #nonce-based-csp}

サーバーで HTML ページをレンダリングする場合は、ノンスベースの厳格な CSP を使用します。

サーバーサイドのすべてのリクエストに対して新しいスクリプト nonce 値を生成し、次のヘッダーを設定します。

サーバー構成ファイル

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>

Google フォトは、ノンスベースの厳格な CSP の良い例です。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 を評価するのに適したツールであると同時に、nonce ベースの厳格な CSP の優れた例でもあります。DevTools を使用して、その使用方法を確認します。

サポートされているブラウザ

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, '&lt;').replace(/>/g, '&gt;');
    }
  });
}


// Assignment of raw strings is blocked by Trusted Types.
el.innerHTML = &#39;some string&#39;; // This throws an exception.

// Assignment of Trusted Types is accepted safely.
const escaped = policy.createHTML(&#39;&lt;img src=x onerror=alert(1)&gt;&#39;);
el.innerHTML = escaped;  // &#39;&amp;lt;img src=x onerror=alert(1)&amp;gt;&#39;
Trusted Types の使用方法

  1. 危険な DOM シンクに Trusted Types を適用する CSP と Trusted Types ヘッダー: 

    Content-Security-Policy: require-trusted-types-for 'script'

    現時点では、require-trusted-types-for ディレクティブで指定できる値は 'script' のみです。

    もちろん、Trusted Types を他の CSP ディレクティブと組み合わせることもできます。

上記の nonce ベースの CSP を Trusted Types と統合します。

Content-Security-Policy:
  script-src &#39;nonce-{RANDOM1}&#39; &#39;strict-dynamic&#39; https: &#39;unsafe-inline&#39;;
  object-src &#39;none&#39;;
  base-uri &#39;none&#39;;
  require-trusted-types-for &#39;script&#39;;




<aside class="note"><b>注: </b>  追加の <code>trusted-types</code> ディレクティブ（例: <code>trusted-types myPolicy</code>）を設定することで、許可される Trusted Types ポリシー名を制限できますが、これは必須ではありません。</aside>


    
  
  1. 
    
    ポリシーを定義する
    
    
    ポリシー:
    
    
    // Feature detection
if (window.trustedTypes && trustedTypes.createPolicy) {
  // Name and create a policy
  const policy = trustedTypes.createPolicy('escapePolicy', {
    createHTML: str => {
      return str.replace(/\/g, '>');
    }
  });
}
    
    
  
    2. 
  
  2. 
    
    ポリシーを適用する
    
    
    DOM にデータを書き込むときにポリシーを使用します。
    
    
    // Assignment of raw strings are blocked by Trusted Types.
el.innerHTML = &#39;some string&#39;; // This throws an exception.</p>

<p>// Assignment of Trusted Types is accepted safely.
const escaped = policy.createHTML(&#39;<img src="x" onerror="alert(1)">&#39;);
el.innerHTML = escaped;  // &#39;&lt;img src=x onerror=alert(1)&gt;&#39;
    
    
    require-trusted-types-for 'script' では、信頼できる型を使用することが要件です。文字列で危険な DOM API を使用すると、エラーが発生します。
    
  
    3. 



サポートされているブラウザ



  
    
    
    
    
  
  
  
    
      
    
  
    
      
    
  
    
      
    
  
    
      
    
  
    
      
    
   

    
    
      
    
    
    
  


その他の情報

X-Content-Type-Options

悪意のある HTML ドキュメントがドメインから配信されると（たとえば、写真サービスにアップロードされた画像に有効な HTML マークアップが含まれている場合）、一部のブラウザはそれをアクティブなドキュメントとして扱い、アプリケーションのコンテキストでスクリプトを実行できるようにします。これにより、クロスサイト スクリプティング バグが発生します。

X-Content-Type-Options: nosniff は、特定のレスポンスの Content-Type ヘッダーで設定された MIME タイプが正しいことをブラウザに指示することで、これを防ぎます。このヘッダーは、すべてのリソースに推奨されます。

使用例

X-Content-Type-Options: nosniff
X-Content-Type-Options の使用方法

サーバーから配信されるすべてのリソースには、正しい Content-Type ヘッダーとともに X-Content-Type-Options: nosniff を使用することをおすすめします。

X-Content-Type-Options: nosniff

ドキュメント HTML とともに送信されるヘッダーの例

X-Content-Type-Options: nosniff
Content-Type: text/html; charset=utf-8

サポートされているブラウザ

Browser Support

  • Chrome: 64.
  • Edge: 12.
  • Firefox: 50.
  • Safari: 11.

Source

その他の情報

X-Frame-Options

悪意のあるウェブサイトがサイトを iframe として埋め込むと、攻撃者がクリックジャッキングによってユーザーに意図しない操作をさせることが可能になる可能性があります。また、場合によっては、Spectre 型の攻撃により、悪意のあるウェブサイトが埋め込みドキュメントの内容を把握する可能性があります。

X-Frame-Options は、ブラウザに <frame>、<iframe>、<embed>、または <object> でのページのレンダリングを許可するかどうかを示します。すべてのドキュメントで、他のドキュメントによる埋め込みを許可するかどうかを示すために、このヘッダーを送信することが推奨されます。

使用例

X-Frame-Options: DENY
X-Frame-Options の使用方法

埋め込みを想定していないすべてのドキュメントで X-Frame-Options ヘッダーを使用する必要があります。

次の構成が iframe の読み込みにどのように影響するかは、こちらのデモでお試しいただけます。X-Frame-Options プルダウン メニューを変更し、[iframe を再読み込み] ボタンをクリックします。

他のウェブサイトによる埋め込みからウェブサイトを保護します

他のドキュメントに埋め込まれることを拒否します。

X-Frame-Options: DENY 
X-Frame-Options: DENY

クロスオリジン ウェブサイトによるウェブサイトの埋め込みを防止する

同じオリジンのドキュメントによる埋め込みのみを許可します。

X-Frame-Options: SAMEORIGIN

サポートされているブラウザ

Browser Support

  • Chrome: 4.
  • Edge: 12.
  • Firefox: 4.
  • Safari: 4.

Source

その他の情報

クロスオリジン リソース ポリシー（CORP）

攻撃者は、別のオリジン（サイトなど）からリソースを埋め込み、ウェブベースのクロスサイト リークを悪用してリソースに関する情報を取得できます。

Cross-Origin-Resource-Policy は、読み込み可能なウェブサイトのセットを示すことで、このリスクを軽減します。ヘッダーは same-origin、same-site、cross-origin の 3 つの値のいずれかを取ります。すべてのリソースで、他のウェブサイトによる読み込みを許可するかどうかを示すために、このヘッダーを送信することが推奨されます。

使用例

Cross-Origin-Resource-Policy: same-origin
CORP の使用方法

すべてのリソースを次の 3 つのヘッダーのいずれかで配信することをおすすめします。

こちらのデモでは、次の構成が Cross-Origin-Embedder-Policy: require-corp 環境でのリソースの読み込みにどのように影響するかを試すことができます。[Cross-Origin-Resource-Policy] プルダウン メニューを変更し、[Reload the iframe] または [Reload the image] ボタンをクリックして、効果を確認します。

リソースの読み込みを許可する cross-origin

CDN のようなサービスでは、cross-origin をリソースに適用することをおすすめします（通常、クロスオリジン ページによって読み込まれるため）。ただし、同様の効果がある CORS を介してすでに提供されている場合は除きます。

Cross-Origin-Resource-Policy: cross-origin 
Cross-Origin-Resource-Policy: cross-origin

same-origin から読み込むリソースを制限する

same-origin は、同一オリジン ページでのみ読み込まれるリソースに適用する必要があります。これは、ユーザーの機密情報を含むリソースや、同じオリジンからのみ呼び出される API のレスポンスに適用する必要があります。

このヘッダーを含むリソースは、たとえばブラウザの新しいウィンドウで URL に移動するなどして、直接読み込むことができることに注意してください。クロスオリジン リソース ポリシーは、他のウェブサイトによるリソースの埋め込みのみを保護します。

Cross-Origin-Resource-Policy: same-origin 
Cross-Origin-Resource-Policy: same-origin

same-site から読み込むリソースを制限する

same-site は、上記と類似しているが、サイトの他のサブドメインによって読み込まれることを想定しているリソースに適用することをおすすめします。

Cross-Origin-Resource-Policy: same-site 
Cross-Origin-Resource-Policy: same-site

サポートされているブラウザ

Browser Support

  • Chrome: 73.
  • Edge: 79.
  • Firefox: 74.
  • Safari: 12.

Source

その他の情報

クロスオリジンのオープナー ポリシー（COOP）

攻撃者のウェブサイトは、ウェブベースのクロスサイト リークを悪用して、ポップアップ ウィンドウで別のサイトを開き、そのサイトに関する情報を取得できます。場合によっては、Spectre に基づくサイドチャネル攻撃の悪用も可能になることがあります。

Cross-Origin-Opener-Policy ヘッダーは、window.open() または rel="noopener" なしの target="_blank" を含むリンクを介して開かれたクロスオリジン ウィンドウからドキュメントを分離する方法を提供します。その結果、ドキュメントのクロスオリジン オープナーはドキュメントへの参照を持たなくなり、ドキュメントとやり取りできなくなります。

使用例

Cross-Origin-Opener-Policy: same-origin-allow-popups
COOP の使用方法

次の構成がクロスオリジン ポップアップ ウィンドウとの通信にどのように影響するかは、こちらのデモでお試しいただけます。ドキュメントとポップアップ ウィンドウの両方の Cross-Origin-Opener-Policy プルダウン メニューを変更し、[Open a popup] ボタンをクリックしてから [Send a postMessage] をクリックして、メッセージが実際に配信されるかどうかを確認します。

クロスオリジン ウィンドウからドキュメントを分離する

same-origin を設定すると、ドキュメントがクロスオリジン ドキュメント ウィンドウから分離されます。

Cross-Origin-Opener-Policy: same-origin 
Cross-Origin-Opener-Policy: same-origin

クロスオリジン ウィンドウからドキュメントを分離するが、ポップアップは許可する

same-origin-allow-popups を設定すると、ドキュメントは、COOP を same-origin または same-origin-allow-popups で設定しない限り、ポップアップ ウィンドウへの参照を保持できます。つまり、same-origin-allow-popups は、ポップアップ ウィンドウとして開かれたドキュメントが参照されないように保護しながら、独自のポップアップとの通信を許可できます。

Cross-Origin-Opener-Policy: same-origin-allow-popups 
Cross-Origin-Opener-Policy: same-origin-allow-popups

ドキュメントがクロスオリジン ウィンドウから参照されることを許可する

unsafe-none がデフォルト値ですが、このドキュメントをクロスオリジン ウィンドウで開いて相互アクセスを維持できることを明示的に示すこともできます。

Cross-Origin-Opener-Policy: 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"

サポートされているブラウザ

Browser Support

  • Chrome: 83.
  • Edge: 83.
  • Firefox: 79.
  • Safari: 15.2.

Source

その他の情報

クロスオリジン リソース シェアリング（CORS）

この記事の他の項目とは異なり、クロスオリジン リソース シェアリング（CORS）はヘッダーではなく、クロスオリジン リソースへのアクセスをリクエストして許可するブラウザ メカニズムです。

デフォルトでは、ブラウザは同一オリジン ポリシーを適用して、ウェブページがクロスオリジン リソースにアクセスできないようにします。たとえば、クロスオリジン画像が読み込まれた場合、ウェブページに視覚的に表示されていても、ページの JavaScript は画像のデータにアクセスできません。リソース プロバイダは、CORS を使用してオプトインすることで、制限を緩和し、他のウェブサイトがリソースを読み取れるようにすることができます。

使用例

Access-Control-Allow-Origin: https://example.com
Access-Control-Allow-Credentials: true
CORS の使用方法

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 環境で単純なリクエストがリソースの読み込みに与える影響をお試しいただけます。[クロスオリジン リソース シェアリング] チェックボックスをオンにして、[Reload the image] ボタンをクリックすると、効果を確認できます。

プリフライト リクエスト

プリフライトされたリクエストの前に 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-Type の HTTP ヘッダーを設定できます。

レスポンス ヘッダーの例

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 秒間キャッシュに保存できることを示します。

サポートされているブラウザ

Browser Support

  • Chrome: 4.
  • Edge: 12.
  • Firefox: 3.5.
  • Safari: 4.

Source

その他の情報

クロスオリジンの埋め込みポリシー（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 の使用方法

使用例

COEP は require-corp の単一の値を受け取ります。このヘッダーを送信することで、CORS または CORP を介してオプトインしていないリソースの読み込みをブロックするようブラウザに指示できます。

COEP の仕組み

次の構成がリソースの読み込みにどのように影響するかは、こちらのデモでお試しいただけます。[Cross-Origin-Embedder-Policy] プルダウン メニュー、[Cross-Origin-Resource-Policy] プルダウン メニュー、[レポートのみ] チェックボックスなどを変更して、リソースの読み込みにどのように影響するかを確認します。また、レポート エンドポイントのデモを開いて、ブロックされたリソースが報告されているかどうかを確認します。

クロスオリジン分離を有効にする

Cross-Origin-Opener-Policy: same-origin とともに Cross-Origin-Embedder-Policy: require-corp を送信して、クロスオリジン分離を有効にします。

Cross-Origin-Embedder-Policy: require-corp
Cross-Origin-Opener-Policy: same-origin

COEP と互換性のないリソースを報告する

Reporting API を使用すると、COEP が原因でブロックされたリソースのレポートを受け取ることができます。

Cross-Origin-Embedder-Policy: require-corp; report-to="coep"

COEP はレポート専用モードもサポートしているため、リソースの読み込みを実際にブロックすることなくレポートを受け取ることができます。

Cross-Origin-Embedder-Policy-Report-Only: require-corp; report-to="coep"

サポートされているブラウザ

Browser Support

  • Chrome: 83.
  • Edge: 83.
  • Firefox: 79.
  • Safari: 15.2.

Source

その他の情報

HTTP Strict Transport Security（HSTS）

プレーン HTTP 接続を介した通信は暗号化されないため、転送されたデータはネットワーク レベルの盗聴者にアクセスされる可能性があります。

Strict-Transport-Security ヘッダーは、HTTP を使用してサイトを読み込まず、代わりに HTTPS を使用するようブラウザに通知します。設定されると、ブラウザはヘッダーで定義された期間、リダイレクトなしで HTTP ではなく HTTPS を使用してドメインにアクセスします。

使用例

Strict-Transport-Security: max-age=31536000
HSTS の使用方法

HTTP から HTTPS に移行するすべてのウェブサイトは、HTTP でリクエストを受信したときに Strict-Transport-Security ヘッダーで応答する必要があります。

Strict-Transport-Security: max-age=31536000

サポートされているブラウザ

Browser Support

  • Chrome: 4.
  • Edge: 12.
  • Firefox: 4.
  • Safari: 7.

Source

その他の情報

関連情報

前へ
「same-site」と「same-origin」について