HTTP Strict Transport Security(HSTS).

HSTS は RFC 6797 で定義されており、応答ヘッダー Strict-Transport-Security によって伝えられます。対応ブラウザは HTTPS 経由でヘッダーを受信すると、宣言された max-age の間ポリシーを記憶し、そのホスト(必要に応じてサブドメインも)に対する以後のリクエストを自動的に HTTPS に切り替えます。TLS ハンドシェイクや証明書検証に失敗した場合は接続を拒否します。これにより、SSL ストリッピング攻撃(Moxie Marlinspike が 2009 年に公開した sslstrip)や平文での Cookie 注入を無効化できます。

HSTS には構造的な弱点があります。それが 初回利用時の信頼(trust-on-first-use) です。ブラウザがヘッダーを一度も見ていない状態では、まさにその最初のリクエストが傍受・ダウングレードされ得ます。プリロードリスト は Chromium・Firefox・Safari・Edge にハードコードされた集合で、ポリシーをブラウザ自体とともに配布することでこの隙を塞ぎ、初回訪問でも HTTPS を強制します。申請には少なくとも 31536000(1 年)の max-age、includeSubDomains、preload ディレクティブが必要で、hstspreload.org から行います。Google Registry は .dev や .app といった gTLD 全体をプリロード済みで、その配下のあらゆるドメインは既定で HTTPS 専用です。注意点として、プリロードリストからの削除は反映が遅いため、恒久的に HTTPS を維持できる場合にのみ preload を使うべきです。

flowchart TD
  A[ブラウザ: 初回訪問] -->|ポリシー未取得| B{プリロードリストに存在?}
  B -->|はい| C[即座に HTTPS を強制]
  B -->|いいえ| D[平文リクエストの余地 - TOFU リスク]
  D --> E[サーバが Strict-Transport-Security ヘッダーを送信]
  E --> F[ブラウザが max-age 分ポリシーをキャッシュ]
  F --> G[以後の全リクエストを自動で HTTPS 化]
  G -->|証明書が無効| H[ハードフェイル、迂回不可]