検証した主張
「HSTSは最初から長期間・includeSubDomains・preloadを一括でオンにするのが安全だ。」
発見元は調査の入口であり、判定の根拠には使用していません。HSTSは単なるリダイレクトではない
HSTSを受け取ったブラウザは、指定期間中、対象ホストへHTTPSで接続します。サーバー側のAlways Use HTTPSとは作用する場所が違います。証明書障害やHTTP専用のサブドメインが残っていると、利用者がアクセスできなくなる可能性があります。
設定をオフにしても、既にブラウザへ保存された期間が即座に消えるわけではありません。この戻しにくさが初期値を慎重にする理由です。
短い期間で主要経路を試す
公開ページ、ログイン、フォーム、API、すべての利用サブドメインがHTTPSで正常に動くことを先に確認します。その後、短いmax-ageから始め、問題がない期間を観測して延長します。
記事の数値をそのまま設定するのではなく、運用に合う確認期間と障害時の連絡・復旧体制を決めてください。
includeSubDomainsとpreloadは別判断
includeSubDomainsは配下のホストにも影響します。preloadはブラウザの事前登録リストに関わり、公式が示す条件を満たす必要があります。テスト用や外部委託先のサブドメインまで把握してから判断します。
「セキュリティの得点が上がる」だけを理由に、一括で有効化しないでください。
検証条件・対象環境
| 対象プラン | 製品・契約プランで機能と表示範囲が異なる |
|---|---|
| 地域 | 提供地域・利用環境で表示や条件が異なる場合あり |
| 利用面 | Cloudflare Dashboard / Webサイト・API |
| 提供状態 | 2026年9月22日時点の公式公開資料。ダッシュボードの名称・契約条件は変更され得る |
| 実機確認 | Cloudflare公式資料で機能と制限を照合しました。個別のサイト・アカウントで設定変更や攻撃の再現はしていません。 |
| 次回見直し | 2026.10.22 |
よくある質問
HSTSを最初からpreloadまで有効にしてよいですか？
HSTSはブラウザにHTTPS利用を記憶させるため強力ですが、証明書やサブドメインに問題があると復旧しにくくなります。まずHTTPSを全ホストで確認し、短い期間から段階的に試します。
更新履歴
公式資料を確認し、固有の利用情報を含まない一般的な手順・注意点として整理。
実機検証は未実施のため、根拠レベルを公開基準に合わせてAからBに訂正。
情報源
一次情報と発見元を区別し、各ページの公開日と確認日を記録しています。
- HTTP Strict Transport Security
HSTSの段階的設定と戻しにくさ。
公開: 公開日未確認（閲覧日を記録）確認: 2026.09.22 - Universal SSL
エッジ証明書の対象と発行。
公開: 公開日未確認（閲覧日を記録）確認: 2026.09.22 - Always Use HTTPS
HTTPからHTTPSへの転送。
公開: 公開日未確認（閲覧日を記録）確認: 2026.09.22