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

サイトの安全性を確保し、重要な情報をすばやく調べることができるヘッダーについて詳しく説明します。

この記事では、保護するために使用できる最も重要なセキュリティ ヘッダーについて説明します。 測定しますウェブベースのセキュリティ機能を理解し、 ウェブサイトに実装し、リマインダーが必要なときの参考にしてください。

ユーザーの機密情報を扱うウェブサイトに推奨されるセキュリティ ヘッダー:
コンテンツ セキュリティ ポリシー(CSP)
Trusted Types
すべてのウェブサイトで推奨されるセキュリティ ヘッダー:
X-Content-Type-Options
X-Frame-Options
クロスオリジン リソース ポリシー(CORP)
クロスオリジン オープナー ポリシー(COOP)
HTTP Strict Transport Security(HSTS)
高度な機能を持つウェブサイトのセキュリティ ヘッダー:
クロスオリジン リソース シェアリング(CORS)
クロスオリジン エンベディング ポリシー(COEP)
ウェブ上の既知の脅威
セキュリティ ヘッダーの詳細に入る前に、ウェブ上の既知の脅威について理解する セキュリティヘッダーを使用する理由を説明します

セキュリティ ヘッダーの詳細に入る前に、ウェブ上の既知の脅威について理解する セキュリティヘッダーを使用する理由を説明します

インジェクション脆弱性からサイトを保護する

インジェクションの脆弱性は、信頼できないデータがお客様によって 動作に影響を及ぼし、一般的にアプリケーション コードの実行に 使用するスクリプトです。インジェクションによって引き起こされる最も一般的な脆弱性 バグはクロスサイト スクリプト(XSS)を さまざまな形式( XSS保存された XSSDOM ベース XSS 使用できます。

XSS の脆弱性により、通常は攻撃者にユーザーデータへの完全アクセス権が付与される アプリケーションによって処理される情報、および同じウェブ上でホストされているその他の情報によって処理される origin を指定します。

インジェクションに対する従来の防御策には、自動エスケープを一貫して使用 危険な JavaScript の使用を回避するための HTML テンプレート システム ユーザーデータを適切な方法で処理するための API があります。 ユーザー制御の HTML をサニタイズして、ファイルを別のドメインにアップロードできます。

  • コンテンツ セキュリティ ポリシー(CSP)を使用して、配信できるスクリプトを制御する インジェクションのリスクを軽減するために使用します。
  • Trusted Types を使用して、危険なデータに渡されるデータのサニタイズを適用する JavaScript API。
  • X-Content-Type-Options を使用して、ブラウザが ウェブサイトのリソースの MIME タイプを誤って解釈し、 自動的に実行されるようにします。

自分のサイトを他のウェブサイトから分離する

ウェブのオープン性は、ウェブサイトが アプリケーションのセキュリティ要件に違反する可能性があります。これには予期しない 認証されたリクエストを行ったり、同じネットワーク内で別のアプリケーションから アプリケーションのデータを改変または読み取ることができます。

ウェブ分離を弱体化させる一般的な脆弱性は次のとおりです。 クリックジャッキングクロスサイト リクエスト フォージェリ(CSRF)、クロスサイト スクリプト インクルード(XSSI)、さまざまな サイトのクロスサイト リーク

Post-Spectre Web Development を読むことで、 ご覧ください

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

Spectre は、読み込まれたデータを 同じブラウジング コンテキスト グループにグループ化できます。 同一オリジン ポリシーに関係なく適用されます。ブラウザによる機能の制限 悪用される可能性があります。 「クロスオリジン分離」。クロスオリジン分離を使用すると SharedArrayBuffer などの強力な機能を使用する。

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

暗号化の問題は、アプリケーションが Google Cloud 内のデータを完全に暗号化していない 通信し、傍受した攻撃者がユーザーの操作内容を把握し、 必要があります。

不十分な暗号化は、次のような場合に発生することがあります。HTTPS を使用していない、 混合コンテンツSecure を使用せずに Cookie を設定する 属性 (または __Secure 接頭辞)、 または Lax CORS 検証 説明します

コンテンツ セキュリティ ポリシー(CSP)

クロスサイト スクリプティング (XSS)は攻撃です。 Web サイトに脆弱性があり、それによって悪意のあるスクリプトが注入され、 実行されます。

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';
CSP の使用方法

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 でスクリプトを読み込むには、すべての属性の nonce 属性を設定します。 <script> タグに同じ {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 Evaluator は、 CSP を評価すると同時に、厳密なノンスベースの CSP の例も必要です。 DevTools でその使用方法を確認します。

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

CSP に関するその他の注意事項

  • frame-ancestors ディレクティブを使用して、クリックジャッキングを阻止できます。クリックジャッキングは、許可した場合に生じるリスクです。 信頼できないサイトに埋め込まれます。よりシンプルな解決策をご希望の場合は、 X-Frame-Options の場合は読み込みをブロックしますが、frame-ancestors の場合は 特定のオリジンのみを埋め込み者として許可する詳細設定を行います。
  • CSP を使用して、サイトのすべてのリソースが 読み込むことができます。これには、 最近ではほとんどのブラウザで mixed-content
  • また、レポート専用で CSP を モード
  • CSP をヘッダー サーバーサイドとして設定できない場合は、メタとして設定することもできます。 できます。メタタグにレポート専用モードを使用することはできません( 変更される可能性があります)。

その他の情報

Trusted Types

DOM ベース XSS は、 動的コードをサポートするシンクに悪意のあるデータが渡される攻撃 実行(eval().innerHTML など)を行います。

Trusted Types には、書き込み、セキュリティ レビュー、保守を行うためのツールが DOM XSS の影響を受けないアプリケーションですCSP を介して有効にすることで、 危険なウェブ API を制限して、JavaScript コードをデフォルトで保護 信頼できるタイプです。

これらのオブジェクトを作成するには、セキュリティ ポリシーを定義して、 セキュリティ ルール(エスケープやサニタイズなど)が一貫して適用されるように 処理する必要がありますこれらのポリシーは 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'
    

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

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

上記のノンスベースの 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> を設定することで、許可される Trusted Types ポリシー名を制限できます。(例: <code>trusted-types myPolicy</code>)。ただし、これは要件ではありません。&lt;/aside&gt;

  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. ポリシーを適用する

    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 を文字列で使用すると、 エラーが発生します。

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

その他の情報

X-Content-Type-Options

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

X-Content-Type-Options: nosniff は、ブラウザに対して MIME タイプセットが 指定されたレスポンスの Content-Type ヘッダーが正しい。このヘッダーは すべてのリソースに推奨されます。

使用例

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

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

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

対応ブラウザ

  • Chrome: 64。 <ph type="x-smartling-placeholder">
  • Edge: 12。 <ph type="x-smartling-placeholder">
  • Firefox: 50。 <ph type="x-smartling-placeholder">
  • Safari: 11. <ph type="x-smartling-placeholder">

ソース

その他の情報

X-Frame-Options

悪意のあるウェブサイトにサイトを iframe として埋め込める場合、 ユーザーによって意図しない操作が実行される クリックジャッキング。また ケース Spectre-type 攻撃は 不正な Web サイトに埋め込まれたドキュメントのコンテンツについて知る機会が得られます。

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

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

対応ブラウザ

  • Chrome: 4. <ph type="x-smartling-placeholder">
  • Edge: 12。 <ph type="x-smartling-placeholder">
  • Firefox: 4. <ph type="x-smartling-placeholder">
  • Safari: 4. <ph type="x-smartling-placeholder">

ソース

その他の情報

クロスオリジン リソース ポリシー(CORP)

攻撃者は、別の送信元(あなたのサイトなど)からリソースを埋め込む ウェブベースのクロスサイト 漏洩します

Cross-Origin-Resource-Policy では、次のリソースのセットを指定することで、このリスクを軽減します。 ウェブサイトを指定します。ヘッダーは次の 3 つの値のいずれかを取ります。 same-originsame-sitecross-originすべてのリソースは、 このヘッダーを送信して、読み込みを許可するかどうかを できます。

使用例

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

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

次の構成がリソースのロードに与える影響を試すことができます。 このプロジェクトの Cross-Origin-Embedder-Policy: require-corp 環境 デモをご覧ください。 [Cross-Origin-Resource-Policy] プルダウン メニューを開き、[再読み込み iframe または [再読み込み] ボタンをクリックして、効果を確認します。

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

CDN のようなサービスでは、リソースに cross-origin を適用することをおすすめします。 (すでに配信されていない限り、通常はクロスオリジン ページから読み込まれるため) 同様の効果があります。CORS

Cross-Origin-Resource-Policy: クロスオリジン
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

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

対応ブラウザ

  • Chrome: 73。 <ph type="x-smartling-placeholder">
  • Edge: 79。 <ph type="x-smartling-placeholder">
  • Firefox: 74。 <ph type="x-smartling-placeholder">
  • Safari: 12。 <ph type="x-smartling-placeholder">

ソース

その他の情報

クロスオリジン オープナー ポリシー(COOP)

攻撃者の Web サイトは、ポップアップ・ウィンドウで別のサイトを開いて、 ウェブベースのクロスサイト 漏洩します。場合によっては 情報に基づくサイドチャネル攻撃の悪用 Spectre

Cross-Origin-Opener-Policy ヘッダーは、ドキュメントを分離する手段となります。 window.open() を介して開いたクロスオリジン ウィンドウまたは target="_blank"rel="noopener" なし)。その結果、クロスオリジン オープナー そのドキュメントを参照する権限がないため、 できます。

使用例

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

次の構成が、通信にどう影響するかや、 クロスオリジン ポップアップ ウィンドウ(こちらのデモ) 両方のドキュメントの [Cross-Origin-Opener-Policy] プルダウン メニューを変更します。 ポップアップ ウィンドウが表示されたら、[ポップアップを開く] ボタンをクリックしてから [メッセージを 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: invalid-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"

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

対応ブラウザ

  • Chrome: 83。 <ph type="x-smartling-placeholder">
  • Edge: 83。 <ph type="x-smartling-placeholder">
  • Firefox: 79。 <ph type="x-smartling-placeholder">
  • Safari: 15.2。 <ph type="x-smartling-placeholder">

ソース

その他の情報

クロスオリジン リソース シェアリング(CORS)

この記事の他の項目とは異なり、クロスオリジン リソース シェアリング(CORS)は そのものへのアクセスをリクエストして許可するブラウザ メカニズムで、 リソースが含まれています。

デフォルトでは、ブラウザは同一オリジン ポリシーを ウェブページがクロスオリジン リソースにアクセスできないようにします。たとえば、 ウェブページに表示されているにもかかわらず、クロスオリジン画像が読み込まれる ページ上の JavaScript は画像のデータにアクセスできません。 リソース プロバイダは制限を緩和し、他のウェブサイトによる読み取りを許可できる 有効にすることでリソースにアクセスできます

使用例

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

CORS の構成方法を説明する前に、CORS の 区別できます。リクエストの詳細に応じて、リクエストは シンプル リクエストまたはプリフライト リクエストのいずれかに分類されます。

シンプル リクエストの条件:

  • メソッドが GETHEAD、または POST である。
  • カスタム ヘッダーには、AcceptAccept-LanguageContent-LanguageContent-Type
  • Content-Typeapplication/x-www-form-urlencodedです。 multipart/form-datatext/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-PINGOTHERContent-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 は、後続の リクエストを行うには、POSTGETOPTIONS の各メソッドを使用します。
  • Access-Control-Allow-Headers: X-PINGOTHER, Content-Type は後であることを示します。 リクエストには、X-PINGOTHER ヘッダーと Content-Type ヘッダーを含めることができます。
  • Access-Control-Max-Age: 86400 は、プリフライトの結果が 86,400 秒間キャッシュできます。

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

対応ブラウザ

  • Chrome: 4. <ph type="x-smartling-placeholder">
  • Edge: 12。 <ph type="x-smartling-placeholder">
  • Firefox: 3.5。 <ph type="x-smartling-placeholder">
  • Safari: 4. <ph type="x-smartling-placeholder">

ソース

その他の情報

クロスオリジン エンベディング ポリシー(COEP)

スペクター ベースの 攻撃を防御し、 クロスオリジン リソースの窃取、たとえば SharedArrayBufferperformance.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] プルダウン メニュー、[Report Only] チェックボックスなど リソースの読み込みに及ぼす影響を確認できますまた、レポート エンドポイントを開きます。 デモで、ブロックされたリソースが 報告されます。

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

クロスオリジン分離を有効にするために、 Cross-Origin-Embedder-Policy: require-corpCross-Origin-Opener-Policy: same-origin

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

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

COEP によってブロックされたリソースのレポートは、レポートを使用して受信できます。 API

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

COEP はレポート専用モードもサポートしているため、 リソースの読み込みをブロックします。

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

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

対応ブラウザ

  • Chrome: 83。 <ph type="x-smartling-placeholder">
  • Edge: 83。 <ph type="x-smartling-placeholder">
  • Firefox: 79。 <ph type="x-smartling-placeholder">
  • Safari: 15.2。 <ph type="x-smartling-placeholder">

ソース

その他の情報

HTTP Strict Transport Security(HSTS)

プレーン HTTP 接続を介した通信は暗号化されないため、 ネットワーク レベルの傍受者が転送データにアクセスできます。

Strict-Transport-Security ヘッダーは、読み込まないことをブラウザに通知します。 HTTP と HTTPS を使用します。設定されるとブラウザは 一定時間リダイレクトなしでドメインにアクセスするため、HTTP ではなく HTTPS 定義します。

使用例

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

HTTP から HTTPS に移行するすべてのウェブサイトは、 Strict-Transport-Security ヘッダー(HTTP を含むリクエストを受信したとき)

Strict-Transport-Security: max-age=31536000

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

対応ブラウザ

  • Chrome: 4. <ph type="x-smartling-placeholder">
  • Edge: 12。 <ph type="x-smartling-placeholder">
  • Firefox: 4. <ph type="x-smartling-placeholder">
  • Safari: 7. <ph type="x-smartling-placeholder">

ソース

その他の情報

関連情報