HSTS Preload要件とは？プリロードリストの登録条件・設定方法・診断基準

HSTS Preload要件とは

HSTS Preload要件とは、HSTSヘッダーが、ブラウザのHSTSプリロードリストに登録するための条件、つまり max-ageが1年以上、includeSubDomains、preload の3点 をそろえているかどうかのことです。プリロードリストは、主要ブラウザにあらかじめ組み込まれた「最初からHTTPSでしか接続しないドメイン」の一覧で、HSTSの弱点である初回訪問時の無防備な状態を解消します。

効果は大きい一方、登録の取り消しには長い時間がかかり、ドメイン配下のすべてのサブドメインに影響します。そのためセキュリティAIチェッカーでは、条件を満たしているかを参考情報として評価し、重みを1（重大度low）に抑えています。

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

HSTSプリロードはなぜ必要なのか

プリロードが解決する問題（初回訪問の無防備）

HSTSは、ブラウザが一度HTTPSでサイトに接続してヘッダーを受け取るまで効きません（MDN）。初めて訪れる住民、ブラウザを新しくした住民、記録の期限が切れた住民は、最初のHTTPリクエストを経路上で横取りされる可能性があります。WSTG-CRYP-01も、HTTPからHTTPSへの転送はsslstripのようなツールで妨害されうるため、プリロードリストへの登録が防御になると述べています。

プリロードリストに登録されたドメインは、ブラウザの出荷時点で「HTTPS限定」と記録されているため、初回からHTTPSで接続されます。Googleが運営するプリロードサービス（hstspreload.org）のリストは主要ブラウザで利用されていますが、HSTSの仕様（RFC 6797）そのものの一部ではありません（MDN）。

hstspreload.orgの登録要件

1. 有効な証明書を提供すること。
2. ポート80で待ち受けている場合、同じホストのHTTPSへ転送すること。
3. すべてのサブドメインをHTTPSで提供すること（とくに www サブドメインがDNSに存在する場合）。
4. ベースドメインのHTTPS応答に、次のHSTSヘッダーを付けること。
   • max-age が31536000秒（1年）以上
   • includeSubDomains を指定
   • preload を指定
   • HTTPSサイトから転送する場合、その転送応答にもHSTSヘッダーを付ける

各要素の詳しい基準は、「HSTSの有効期間」、「HSTSをサブドメインにも適用」、「HTTPからHTTPSへ転送」の各項目で解説しています。

登録の取り消しが難しいこと

hstspreload.orgは、プリロードリストへの登録は簡単には取り消せず、削除が利用者のブラウザに反映されるまで数か月かかると明記しています。登録すると、そのドメイン配下のすべてのホストがHTTPS必須になり、HTTPSに対応できないサブドメインは、削除が反映されるまで閲覧できなくなります。OWASP Cheat Sheetも、preload ディレクティブは不適切に実装するとサイトにアクセスできなくなる重大な結果を招くと注意しています。

HSTSプリロードについてよくある誤解

• 「ヘッダーにpreloadと書けば登録される」：preload は登録の意思表示にすぎません。実際の登録には、hstspreload.orgでの申請が必要です。逆に、意図せず preload を書いたヘッダーを第三者が申請してしまう可能性もあるため、登録するつもりがないなら書かないでください。
• 「www.のホストだけ登録できる」：要件はベースドメインでのヘッダーを求めています。登録の効果はドメイン配下全体に及びます。
• 「どの自治体も登録すべき」：ASVS 5.0.0でもプリロード登録はレベル3（高い保証が必要なアプリケーション向け）の要件です。サブドメインの管理体制が整っていない段階での登録は、むしろ障害の原因になります。

HSTS Preload要件の診断基準（セキュリティAIチェッカー）

取得方法

• 最終応答（HTTPS）の Strict-Transport-Security ヘッダー（先頭の1つ）から、max-age の値、includeSubDomains と preload の有無を、大文字・小文字を区別せずに確認します。
• 評価の前提として、「HSTSが設定されている」が○（HTTPS応答で、1以上の max-age を持つHSTSがある）である必要があります。

判定条件

• この項目はヘッダーの書式要件だけを確認します。実際にプリロードリストへ登録済みかどうか、ベースドメインでのヘッダー、すべてのサブドメインのHTTPS対応、HTTPから同一ホストへの転送は確認しません。○は「ヘッダー上は登録要件を満たしている」という意味です。
• 重みが1で、未達でも△（0.45点）にとどまるため、全体スコアへの影響は小さく設計しています。登録しない判断をした場合は、△のままで差し支えありません。
• preload が書かれているのに max-age が1年未満、または includeSubDomains がない場合も△です。この組み合わせは登録を申請しても受け付けられないため、設定の見直しが必要です。

自治体サイトでの判定例

HSTS Preload要件を満たさない・誤って登録するとどんなリスクがあるか

• 登録しない場合：初回訪問時やHSTS記録の期限切れ後の最初のHTTPリクエストが、公衆無線LANなどでSSL Strip攻撃を受ける余地が残ります。
• 要件を満たさないpreload指定：preload があるのに要件を満たさない設定は、担当者が「プリロード済み」と誤解する原因になります。
• 準備不足での登録：HTTPS未対応のサブドメイン（施設予約、庁内システム、検証環境など）が残ったまま登録すると、それらは数か月にわたってブラウザから開けなくなります。登録はドメイン配下全体に影響するため、本体サイトの担当課だけでは判断できません。

HSTSプリロードの設定方法と登録手順（Apache・nginx・IIS・Next.js）

登録するかどうかの判断

次のすべてに「はい」と答えられる場合に限り、登録を検討します。

• ドメイン配下のすべてのホスト名を把握し、すべてがHTTPSで動作している。
• 委託先システムや庁内システムも含め、今後もHTTPのみのホストを作らない運用ルールがある。
• 証明書の自動更新と期限監視が確立している。
• max-age=31536000; includeSubDomains を数か月運用し、問題が出ていない。

段階的な手順（hstspreload.orgの推奨に準拠）

1. max-age=300; includeSubDomains → max-age=604800; includeSubDomains → max-age=2592000; includeSubDomains と延ばし、各段階でそのmax-ageの期間が過ぎるまで様子を見る。
2. max-age=63072000; includeSubDomains; preload を、ベースドメインのHTTPS応答（転送応答を含む）に設定する。
3. hstspreload.orgでドメインを確認し、要件を満たしていることを確かめてから申請する。

Apache

<IfModule mod_headers.c>
  Header always set Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" env=HTTPS
</IfModule>

nginx

add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always;

IIS（10.0 version 1709以降）

サイトの <hsts> 要素（applicationHost.config）には preload 属性もあり、3つのディレクティブをまとめて設定できます。IISはHTTPS応答にだけヘッダーを付与します。

<site name="CityWeb">
  <hsts enabled="true" max-age="63072000" includeSubDomains="true" preload="true" redirectHttpToHttps="true" />
</site>

web.config の customHeaders でも同じヘッダーを付けられますが、<hsts> と併用すると重複するため、どちらか一方にします。Microsoftの資料は、preload 属性をプリロードリストへ申請するドメインに限って有効にするよう注意しています。

Next.js（Vercel）

headers: [{ key: "Strict-Transport-Security", value: "max-age=63072000; includeSubDomains; preload" }]

設定の確認方法

curl -sI https://city.example.lg.jp/ | grep -iE '^(HTTP/|strict-transport-security|location)'
curl -sI http://city.example.lg.jp/  | grep -iE '^(HTTP/|location)'   # 同じホストのHTTPSへ転送されるか

サイトを壊さないための注意点

• 登録するつもりがない場合は、ヘッダーに preload を書かないでください。
• 登録後にHTTPS未対応のサブドメインが必要になっても、すぐには対応できません。新しいサブドメインを作る際の手順書に「HTTPS必須」を明記します。
• 登録の取り消しはhstspreload.orgの削除フォームから申請できますが、利用者のブラウザに反映されるまで数か月かかります。

よくある質問（FAQ）

参考資料

• HSTS Preload List Submission（hstspreload.org）
• OWASP ASVS 5.0.0 V3 Web Frontend Security（V3.4.1、V3.7.4）
• RFC 6797 HTTP Strict Transport Security
• MDN Strict-Transport-Security
• OWASP HTTP Strict Transport Security Cheat Sheet
• OWASP WSTG-CRYP-01 Testing for Weak Transport Layer Security
• OWASP WSTG-CONF-07 Test HTTP Strict Transport Security
• Microsoft Learn「HSTS Settings for a Web Site <hsts>」
• Vercel Docs「Encryption and TLS」

「HSTS Preload要件」と関連する診断項目

• HSTSの有効期間medium
• HSTSをサブドメインにも適用medium
• HTTPからHTTPSへ転送high
• HSTSが設定されているhigh
• HSTSを全HTTPS応答へ適用high
• HTTPSで配信されているcritical
• TLS証明書が現在有効critical
• 証明書チェーンが信頼されるhigh