Web セキュリティ

HSTS (HTTP Strict Transport Security)

約 4 分で読めます

最終更新: 2026-09-01

HSTS とは

HSTS (HTTP Strict Transport Security) は、Web サーバーがブラウザに対して「今後このドメインへのアクセスは必ず HTTPS を使うように」と指示するセキュリティ機構です。HTTP レスポンスヘッダーに Strict-Transport-Security を付与することで有効化され、仕様は RFC 6797 (2012 年 11 月) で標準化されています。

HSTS が設定されていない場合、ユーザーが http://example.com にアクセスすると、サーバーが HTTPS へリダイレクトするまでの一瞬、通信が平文で行われます。この瞬間を狙った中間者攻撃 (SSL ストリッピング) が成立する余地があります。HSTS を受け取ったブラウザは、以降その URL を送信する前に HTTPS へ書き換えるため、この平文の往復自体が発生しなくなります。

もう一つの柱が証明書エラーの扱いです。HSTS が有効なドメインで証明書の検証に失敗した場合、ブラウザは接続を中断しなければならず、通常の警告画面のように利用者が「危険を承知で進む」ことはできません。攻撃者が偽の証明書を用意しても、利用者の操作で押し通せない点が通常の HTTPS との違いです。

一方で、ブラウザがこの指示を知るのはヘッダーを受け取った後です。そのドメインへ初めてアクセスする 1 回目は HSTS が働かず、RFC 自身もこれを弱点として挙げています。後述の Preload リストは、この穴を埋めるために用意された仕組みです。

HSTS の設定とディレクティブ

HSTS は以下のレスポンスヘッダーで設定します。

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

  • max-age: ブラウザが HSTS ポリシーを記憶する秒数。31536000 (1 年) は Preload リストの登録要件が下限として求める値でもあり、よく使われる。初回導入時は 300 (5 分) や 86400 (1 日) から始め、問題がなければ段階的に延長するのが安全。
  • includeSubDomains: サブドメインにも HSTS を適用する。api.example.com や cdn.example.com など、すべてのサブドメインが HTTPS に対応していることを確認してから有効化する。HTTP のみで運用しているサブドメインがあると、そのサブドメインにアクセスできなくなる。
  • preload: HSTS Preload リストへの登録意思を示すフラグ。RFC 6797 が定義しているのは max-age と includeSubDomains の 2 つで、preload はブラウザ側のリストのために後から追加された仕様外のフラグ。仕様は知らないディレクティブを無視するよう定めているため、付けただけでは何も起こらず、登録には別途申請が必要。

セキュリティヘッダーの中でも HSTS は設定項目が少なく、TLS/SSL による暗号化通信を確実に強制できます。ただし、いったんブラウザに記憶されると max-age が切れるまでそのドメインを HTTP へ戻せません。HTTPS 対応が済んでいる範囲を見極め、max-age を小さく始めて延ばしていく手順が安全です。

HSTS Preload リストの仕組み

通常の HSTS には「初回アクセス問題」があります。ブラウザが HSTS ヘッダーを受け取るのは最初の HTTPS アクセス時であるため、ユーザーがそのドメインに初めてアクセスする際は HSTS が機能しません。

この問題に対処するのが HSTS Preload リストです。これはブラウザに組み込まれた HSTS 対応ドメインの一覧で、Chrome のソースコードに含まれるリストが元になっており、Firefox・Safari・Edge もこれを基にしたリストを持っています。登録の申請は hstspreload.org から行い、登録されると、ユーザーが一度もアクセスしたことがないドメインでも、最初から HTTPS が強制されます。

Preload リスト登録の要件は以下のとおりです。

  • 有効なデジタル証明書を使用していること
  • ポート 80 で待ち受けている場合、同じホスト名で HTTP から HTTPS へリダイレクトすること
  • すべてのサブドメインを HTTPS で提供していること (www の DNS レコードがあれば www も対象。外部に公開していない社内向けサブドメインも含む)
  • max-age が 31536000 (1 年) 以上であること
  • includeSubDomains と preload ディレクティブが含まれていること

注意点は元に戻しにくさです。削除を申請しても、その変更がブラウザの更新を通じて利用者に届くまで数か月かかり、Chrome 以外のブラウザについては反映が保証されないと明記されています。新規登録も同様に、安定版へ届くまで数か月を要します。登録前に、すべてのサブドメインが HTTPS に対応していることを慎重に確認してください。

なお hstspreload.org は 2026 年 8 月時点で、HSTS 自体は推奨する一方、Preload リストへの登録は推奨しないという立場を示しています。Chrome や Safari が HSTS ポリシーの有無に関係なく HTTP のページ遷移を HTTPS へ格上げするようになり、Preload が効くのはその格上げが攻撃者に妨げられた場面に限られるためです。HSTS の導入と Preload リストへの登録は、別の判断として扱ってください。

HSTS 導入時の注意点と段階的アプローチ

HSTS は強力な反面、設定ミスがサイトのアクセス不能につながるリスクがあります。以下の段階的アプローチを推奨します。

  1. Step 1: max-age=300 (5 分) で設定し、サイト全体が HTTPS で正常に動作することを確認
  2. Step 2: max-age=86400 (1 日) に延長し、1 週間程度運用して問題がないことを確認
  3. Step 3: max-age=31536000; includeSubDomains に拡大
  4. Step 4: Preload リストへの登録を選ぶ場合のみ、前節の注意点を確認したうえで preload を追加して申請

特に注意すべきは、自分のドメインやそのサブドメインを HTTP で参照している箇所です。includeSubDomains を有効にすると、これらの参照はブラウザが HTTPS へ書き換えるため、HTTPS に対応していないサブドメインがあると読み込み自体が失敗します。有効化する前に、検証環境や社内向けを含めたすべてのサブドメインが HTTPS で応答することを確認してください。なお他社ドメインの CDN が HTTP で配信しているリソースは HSTS の適用範囲外で、そちらは HSTS の有無に関わらず混在コンテンツ (Mixed Content) としてブラウザに遮断されます。

CSP の upgrade-insecure-requests ディレクティブと併用すると、ページ内の HTTP リソース参照を自動的に HTTPS に書き換えてくれるため、移行期間中の混在コンテンツ問題を緩和できます。

よくある誤解

HTTPS にリダイレクトしていれば HSTS は不要
HTTP から HTTPS へのリダイレクト中、最初のリクエストは平文で送信されます。この瞬間に中間者攻撃 (SSL ストリッピング) が成立する可能性があります。HSTS はブラウザ側で HTTP リクエスト自体を HTTPS に書き換えるため、リダイレクトでは防げない攻撃を防御します。
HSTS を設定すれば即座にすべてのユーザーに適用される
通常の HSTS はブラウザがヘッダーを受信して初めて有効になるため、初回アクセス時は保護されません。初回から強制する手段としては HSTS Preload リストがありますが、登録すると元に戻すまでに数か月かかるため、対象のドメインとすべてのサブドメインを長期にわたり HTTPS で維持できるかを見極めてから判断します。
共有する

関連用語

関連記事

← 用語集