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

強力な HSTS ポリシーを使用する

HTTP などのプレーンテキストプロトコルは、攻撃者が送信されたコンテンツを読み取ることができる盗聴攻撃に対して脆弱になる可能性があります。Transport Layer Security（TLS）はトラフィックを暗号化し、攻撃者がこのデータをキャプチャしても使用できないようにします。

ただし、攻撃者が暗号化された接続に平文 HTTP を強制することで、TLS を回避する可能性があります。この問題に対処するには、HTTP Strict Transport Security（HSTS）レスポンスヘッダーを使用します。HSTS は、ユーザーのブラウザが TLS を使用してウェブサイトにアクセスするように強制し、一定期間は平文 HTTP にフォールバックすることを許可しません。

Browser Support

Source

Lighthouse 監査が失敗する仕組み

HSTS レスポンスヘッダーが見つからなかったことを示す Lighthouse レポートの警告。

監査では、HSTS ヘッダーに関する次の問題が報告されます。

HSTS ヘッダーがまったく見つからない場合。
推奨ディレクティブのいずれかが欠落している場合（max-age、includeSubDomains、preload）
max-age ディレクティブの期間が 1 年（31,536,000 秒）未満の場合。
不明なディレクティブなど、ヘッダーの解析時に構文エラーが発生した場合。

強力な HSTS ポリシーを構成する

最適な HSTS ヘッダー構成は次のようになります。

Strict-Transport-Security: max-age=63072000; includeSubDomains; preload

max-age ディレクティブは、ユーザーのブラウザが TLS のみを使用してウェブサイトにアクセスすることを強制される時間（秒単位）を指定します。有効期限が切れると、ウェブサイトから HSTS ヘッダーが提供されていない場合（または HTTP から HTTPS への一時的なリダイレクト）、ユーザーは再びプレーンな HTTP でサイトにアクセスできるようになります。
includeSubDomains ディレクティブを設定すると、ヘッダーを最初に送信したページの URL のサブドメインにヘッダーが適用されます。たとえば、includeSubDomains ディレクティブを含む HSTS ヘッダーが google.com によって送信されると、mail.google.com に HSTS ヘッダーが適用されます。
preload ディレクティブを設定して、HSTS プリロードサービスにドメインを送信すると、プリロードされた HSTS リストを使用するブラウザバイナリにドメインがコンパイルされます。これは Google Chrome だけでなく、他のブラウザにも当てはまります。

HSTS ヘッダーのロールアウトには、いくつかのリスクがあります。暗号化されていない HTTP 接続を必要とする機能は、max-age ディレクティブで設定された時間、実質的に機能しなくなります。preload ディレクティブが適用されている場合は、さらに長くなる可能性があります。

ロールアウトに伴うリスクを軽減するため、段階的なアプローチをおすすめします。

小さな max-age から始め、includeSubDomains のみを追加します（preload は追加しません）。
```
max-age=3600; includeSubDomains
```
問題の報告がないクールダウン期間（1 週間など）が経過したら、max-age を引き上げます。次に例を示します。
```
max-age=604800; includeSubDomains
```
この初期フェーズが長期間（3 か月など）成功した場合は、ウェブサイトとそのサブドメインを HSTS プリロードリストに追加し、preload ディレクティブを追加する必要があります。
```
max-age=63072000; includeSubDomains; preload
```

強力な HSTS ポリシーを使用する コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。

Lighthouse 監査が失敗する仕組み

強力な HSTS ポリシーを構成する

強力な HSTS ポリシーを使用する