このページは Cloud Translation API によって翻訳されました。

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

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

Eiji Kitamura

Artur Janc

Maud Nalpas

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

ユーザーの機密情報を扱うウェブサイトに推奨されるセキュリティヘッダー:: コンテンツセキュリティポリシー（CSP）; Trusted Types
すべてのウェブサイトで推奨されるセキュリティヘッダー:: X-Content-Type-Options; X-Frame オプション; クロスオリジンリソースポリシー（CORP）; クロスオリジンオープナーポリシー（COOP）; HTTP Strict Transport Security（HSTS）
高度な機能を持つウェブサイトのセキュリティヘッダー:: クロスオリジンリソースシェアリング（CORS）; クロスオリジンエンベディングポリシー（COEP）

ウェブ上の既知の脅威

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

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

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

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

インジェクションに対する従来の防御策には、自動エスケープを一貫して使用危険な JavaScript の使用を回避するための HTML テンプレートシステムユーザーデータを適切な方法で処理するための 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 を使用して、次のことを行います。クロスオリジン分離を有効にします

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

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

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

HTTP Strict Transport Security（HSTS）を使用して、常時コンテンツを暗号化します。

コンテンツセキュリティポリシー（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 でその使用方法を確認します。

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

* https: は Safari のフォールバックです。unsafe-inline はかなり古いバージョンのブラウザのフォールバックです。https: と unsafe-inline は、strict-dynamic をサポートするブラウザで無視されるため、ポリシーの安全性が低下することはありません。詳しくは、Safari と古いブラウザに対応するためのフォールバックを追加するをご覧ください。* Safari は strict-dynamic にまだ対応していません。ただし、上記の例のような厳格な CSP は、すべてのユーザーにとって許可リスト CSP よりも安全です（CSP がまったくないよりもはるかに安全です）。Safari でも、厳格な CSP によって一部の種類の XSS 攻撃からサイトが保護されます。CSP が存在すると、特定の安全でないパターンが禁止されるためです。

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

推奨される使用方法

危険な 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;


  
    ポリシーを定義する
    ポリシー:
   // Feature detection
if (window.trustedTypes && trustedTypes.createPolicy) {
  // Name and create a policy
  const policy = trustedTypes.createPolicy('escapePolicy', {
    createHTML: str => {
      return str.replace(/\/g, '>');
    }
  });
}

    注: trusted-types ディレクティブを設定して、許可される Trusted Types ポリシーの名前を制限しない限り、任意の名前でポリシーを定義できます。
  
  
    ポリシーを適用する
    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 を文字列で使用すると、
      エラーが発生します。
  

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

  
    
    
    
    
  
  
  
    
      
    
  
    
      
    
  
    
      
    
  
    
      
    
  
    
      
    
   

    
    
      
    
    
    
  
その他の情報

  Trusted Network で DOM ベースのクロスサイト スクリプティングの脆弱性を防止
      タイプ
  CSP: require-trusted-types-for - HTTP |
      MDN
  CSP: Trusted-types - HTTP |
      MDN
  Trusted Types のデモ - DevTools Inspector を開いて、
    何が起こっているのか



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 ヘッダーを付加します。

ドキュメントの HTML と一緒に送信されるヘッダーの例
X-Content-Type-Options: nosniff
Content-Type: text/html; charset=utf-8

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

  
    
    
    
    
  
  
  
    
      
    
  
    
      
    
  
    
      
    
   

    
    
      
      

        対応ブラウザ
        
          
  
  
    
      
        
          
          
        
      
    
    
  
  64
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  
  12
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  
  50
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  
  11
  
  
        
        
        ソース
        
      
    
    
    
  
その他の情報

  X-Content-Type-Options - HTTP MDN

    
  


X-Frame オプション

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

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

注:  特定の発行元のみにドキュメントの埋め込みを許可するなど、よりきめ細かい制御が必要な場合は、CSP frame-ancestors ディレクティブを使用します。

使用例
X-Frame-Options: DENY


  
    
    X-Frame-Options の使用方法


    
      推奨される使用方法
埋め込み用に設計されていないドキュメントはすべて、X-Frame-Options ヘッダーを使用する必要があります。
次の設定が iframe の読み込みにどのように影響するか、こちらの
    デモをご覧ください。X-Frame-Options を変更する
  プルダウン メニューをクリックし、[iframe の再読み込み] ボタンをクリックします。
他のウェブサイトに埋め込まれないようにウェブサイトを保護する
他のドキュメントによる埋め込みを拒否します。

X-Frame-Options: DENY

クロスオリジン ウェブサイトによる埋め込みからウェブサイトを保護
同一オリジン ドキュメントによる埋め込みのみを許可します。
X-Frame-Options: SAMEORIGIN

 ドキュメントがデフォルトで埋め込み可能になっている場合、ウェブ デベロッパーは、埋め込みを停止してサイドチャネル攻撃から保護するために、DENY または SAMEORIGIN を明示的に送信する必要があります。Chrome チームは、ドキュメントの埋め込みをデフォルトでブロックして、ヘッダーを明示的に設定しなくてもウェブサイトの安全性を確保できるようにすることを検討しています。新しい環境では、ドキュメントを埋め込むには、明示的にオプトインする必要があります。
サポートされているブラウザ

  
    
    
    
    
  
  
  
    
      
    
  
    
      
    
  
    
      
    
   

    
    
      
      

        対応ブラウザ
        
          
  
  
    
      
        
          
          
        
      
    
    
  
  4
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  
  12
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  
  4
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  
  4
  
  
        
        
        ソース
        
      
    
    
    
  
その他の情報

  X-Frame-Options - HTTP

    
  


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

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

Cross-Origin-Resource-Policy では、次のリソースのセットを指定することで、このリスクを軽減します。
ウェブサイトを指定します。ヘッダーは次の 3 つの値のいずれかを取ります。
same-origin、same-site、cross-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

same-origin から読み込まれるリソースを制限する
same-origin は、読み込みのみが想定されているリソースに適用する必要があります
  同じオリジンのページから区別できますこれは、機密データを含むリソースに適用し、
  ユーザーに関する情報、または呼び出される予定の API のレスポンスが
  同じオリジンからのみです。
なお、このヘッダーを含むリソースは、
  新しいブラウザ ウィンドウでこの URL に移動し、サンプルを確認できます。クロスオリジン リソース
  ポリシーは、リソースが他のウェブサイトに埋め込まれないように保護するだけです。

Cross-Origin-Resource-Policy: same-origin

same-site から読み込まれるリソースを制限する
same-site は、上記と同様のリソースに適用することをおすすめします。
  サイトの他のサブドメインで読み込まれるように設計されている。

Cross-Origin-Resource-Policy: same-site

注: 同一オリジンと同一サイトの違いについて詳しくは、「同一サイト」について「same-origin」です。
サポートされているブラウザ

  
    
    
    
    
  
  
  
    
      
    
  
    
      
    
  
    
      
    
   

    
    
      
      

        対応ブラウザ
        
          
  
  
    
      
        
          
          
        
      
    
    
  
  73
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  
  79
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  
  74
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  
  12
  
  
        
        
        ソース
        
      
    
    
    
  
その他の情報

  クロスオリジン リソース ポリシーのデプロイを検討する
  ウェブサイトを「クロスオリジン分離」する（COOP と COEP を使用）
  「クロスオリジン分離」が必要な理由パワフルな機能のために

    
  


クロスオリジン オープナー ポリシー（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

ドキュメントをクロスオリジン ウィンドウから分離し、ポップアップは許可する
same-origin-allow-popups を設定すると、ドキュメントは以下への参照を保持できます。
  （COOP に same-origin または
  same-origin-allow-popups。つまり、same-origin-allow-popups さんは引き続き
  ドキュメントをポップアップ ウィンドウとして開いたときに参照されないように保護する一方で、
  固有のポップアップとの通信を可能にします。


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

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

 unsafe-none がデフォルトの場合、ウェブ デベロッパーは、サイドチャネル攻撃からウェブサイトを保護するために、same-origin または same-origin-allow-popups を明示的に送信する必要があります。で確認できます。
Cross-Origin-Opener-Policy: unsafe-none

注: SharedArrayBuffer や performance.measureUserAgentSpecificMemory() などの機能はデフォルトで無効になっています。一部のブラウザでは、「クロスオリジン分離」で使用できるこれらを使用するには、COOP ヘッダーと COEP ヘッダーを設定する必要があります。詳しくは、ウェブサイトを「クロスオリジン分離」にする”をご覧ください。COOP と COEP を使用する。
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"

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

  
    
    
    
    
  
  
  
    
      
    
  
    
      
    
  
    
      
    
   

    
    
      
      

        対応ブラウザ
        
          
  
  
    
      
        
          
          
        
      
    
    
  
  83
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  
  83
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  
  79
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  
  15.2
  
  
        
        
        ソース
        
      
    
    
    
  
その他の情報

  「クロスオリジン分離」が必要な理由パワフルな機能のために

    
  


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

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

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

使用例
Access-Control-Allow-Origin: https://example.com
Access-Control-Allow-Credentials: true


  
    
    CORS の使用方法


    
      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 環境
    デモをご覧ください。[
  [クロスオリジン リソース シェアリング] チェックボックスをオンにして、[画像の再読み込み] をクリックします。
  その効果を確認します。

プリフライトされたリクエスト
プリフライトされたリクエストの前には 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 秒間キャッシュできます。

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

  
    
    
    
    
  
  
  
    
      
    
  
    
      
    
  
    
      
    
   

    
    
      
      

        対応ブラウザ
        
          
  
  
    
      
        
          
          
        
      
    
    
  
  4
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  
  12
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  
  3.5
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  
  4
  
  
        
        
        ソース
        
      
    
    
    
  
その他の情報

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

    
  


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

スペクター ベースの
攻撃を防御し、
クロスオリジン リソースの窃取、たとえば 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。


次の設定が、こちらの
    デモをご覧ください。
  [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 によってブロックされたリソースのレポートは、レポートを使用して受信できます。
  API
Cross-Origin-Embedder-Policy: require-corp; report-to="coep"

COEP はレポート専用モードもサポートしているため、
  リソースの読み込みをブロックします。
Cross-Origin-Embedder-Policy-Report-Only: require-corp; report-to="coep"

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

  
    
    
    
    
  
  
  
    
      
    
  
    
      
    
  
    
      
    
   

    
    
      
      

        対応ブラウザ
        
          
  
  
    
      
        
          
          
        
      
    
    
  
  83
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  
  83
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  
  79
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  
  15.2
  
  
        
        
        ソース
        
      
    
    
    
  
その他の情報

  ウェブサイトを「クロスオリジン分離」する（COOP と COEP を使用）
  「クロスオリジン分離」が必要な理由パワフルな機能のために
  クロスオリジン分離を有効にするためのガイド

    
  


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

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

  
    
    
    
    
  
  
  
    
      
    
  
    
      
    
  
    
      
    
   

    
    
      
      

        対応ブラウザ
        
          
  
  
    
      
        
          
          
        
      
    
    
  
  4
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  
  12
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  
  4
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  
  7
  
  
        
        
        ソース
        
      
    
    
    
  
その他の情報

  Strict-Transport-Security -
      HTTP

    
  


関連情報


Post-Spectre ウェブ開発

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

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

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

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

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

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

推奨される使用方法

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

2. ハッシュベースで厳格な CSP を使用する {: #hash-based-csp}

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

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

その他の情報

Trusted Types

推奨される使用方法

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

その他の情報

X-Content-Type-Options

推奨される使用方法

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

その他の情報

X-Frame オプション

推奨される使用方法

他のウェブサイトに埋め込まれないようにウェブサイトを保護する

クロスオリジン ウェブサイトによる埋め込みからウェブサイトを保護

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

その他の情報

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

推奨される使用方法

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

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

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

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

その他の情報

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

推奨される使用方法

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

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

クロスオリジン ウィンドウでのドキュメントの参照を許可する

COOP に対応していないレポート パターン

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

その他の情報

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

推奨される使用方法

単純なリクエスト

プリフライトされたリクエスト

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

その他の情報

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

使用例

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

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

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

その他の情報

HTTP Strict Transport Security（HSTS）

推奨される使用方法

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

その他の情報

関連情報

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

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

クロスオリジンウェブサイトによる埋め込みからウェブサイトを保護

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

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

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

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

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

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

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

クロスオリジンウィンドウでのドキュメントの参照を許可する

COOP に対応していないレポートパターン

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

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