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

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

ただし、攻撃者は、暗号化された接続にプレーンテキスト HTTP を使用するように強制することで、TLS を回避できます。この問題に対処するため、HTTP Strict Transport Security(HSTS)レスポンス ヘッダーが導入されました。これにより、ユーザーのブラウザは TLS のみを使用してウェブサイトにアクセスし、プレーンテキスト HTTP にフォールバックしないように強制されます(一定の期間)。

Lighthouse 監査が失敗する仕組み

HSTS レスポンス ヘッダーが見つからないという Lighthouse 監査の警告。
HSTS レスポンス ヘッダーが見つからないという警告が Lighthouse レポートに表示される。

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

  • HSTS ヘッダーがまったく見つからない場合。
  • 推奨されるディレクティブのいずれかが不足している場合(max-ageincludedSubDomainspreload
  • max-age ディレクティブの期間が 1 年未満(31536000 秒)の場合。
  • ヘッダーの解析中に構文エラーが発生した場合(不明なディレクティブなど)。

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

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

Strict-Transport-Security: max-age=63072000; includeSubDomains; preload
  • max-age ディレクティブは、ユーザーのブラウザが TLS のみを使用してウェブサイトにアクセスする必要がある時間を秒単位で指定します。この時間の経過後、ウェブサイトから HSTS ヘッダーが提供されていない場合(または HTTP から HTTPS への一時的なリダイレクトが設定されている場合)、平文の HTTP を使用してサイトにアクセスできるようになります。
  • includeSubDomains ディレクティブを設定すると、最初にヘッダーを送信したページ URL のサブドメインにヘッダーが適用されます。たとえば、google.com から送信された HSTS ヘッダーに includeSubDomains ディレクティブが含まれている場合、mail.google.com にも HSTS ヘッダーが適用されます。
  • preload ディレクティブを設定してドメインを HSTS プリロード サービスに送信すると、ドメインはプリロードされた HSTS リスト(Google Chrome だけでなく)を使用するブラウザ バイナリにコンパイルされます。

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

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

  1. 小さな max-age から始めて、includeSubDomains のみを追加します(preload は追加しません)。

    max-age=3600; includeSubDomains
    
  2. 問題が報告されなかったクールダウン期間(1 週間など)が経過したら、max-age を上げます。次に例を示します。

    max-age=604800; includeSubDomains
    
  3. この初期フェーズが長期間にわたって成功した場合(3 か月など)、ウェブサイトとそのサブドメインを HSTS プリロード リストに追加し、preload ディレクティブを追加する必要があります。

    max-age=63072000; includeSubDomains; preload