![HSTS の効果と副作用](/blog/hsts-smb-side-effects/benefit-vs-risk.svg)

## この記事でわかること

- HSTS が「ブラウザに HTTPS 接続を強制させる仕組み」であること
- 中小企業の Web サイトで HSTS が必要なケース / 不要なケース
- 安易に導入すると業務を止める 3 つの副作用
- 安全に試して恒久化する手順

## HSTS とは何か

HSTS（HTTP Strict Transport Security、エイチエスティーエス）は、Web サーバーから「このサイトには今後 HTTPS でしかアクセスしないでください」とブラウザに指示する仕組みです。HTTP レスポンスヘッダに次のような行を追加するだけで有効になります。

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

`max-age=31536000` は「1 年間有効」の意味です。一度この応答を受け取ったブラウザは、次回以降そのドメインに `http://` でアクセスしても、自動で `https://` に書き換えてから接続します。

HSTS は SSL の正しい運用と組み合わせることで、攻撃者が中間で HTTP に誘導するタイプの攻撃を防ぎます。SSL 自体の役割は[SSL とは｜中小企業向け](/blog/ssl-basics-smb)を参照。

## 中小企業に「絶対必要」ではない

HSTS は強力ですが、すべての中小企業 Web サイトに必須というわけではありません。次のように整理できます。

### HSTS を入れるメリットが大きいケース

- お問い合わせ / 会員登録 / カート / 決済など、フォーム入力動線がある
- 自社運営の EC サイト（決済代行を内蔵していない構成）
- 個人情報・機密情報を扱う業務アプリ
- 公衆 Wi-Fi 経由でアクセスされる可能性がある業務系サイト

### HSTS なしでも実用上問題ないケース

- 静的なコーポレートサイト / ブログ / LP のみで、フォームは外部 SaaS（Google フォーム / Typeform 等）
- 既に `.htaccess` で HTTP → HTTPS の 301 リダイレクトが入っている
- ドメイン構成がシンプル（サブドメインがほぼない、または将来追加予定もない）

HTTP → HTTPS リダイレクトの基本は[Chrome「保護されていない通信」警告の直し方](/blog/chrome-not-secure-warning-fix)に整理しています。

## 知らずに入れると業務を止める 3 つの副作用

![HSTS の 3 つの副作用](/blog/hsts-smb-side-effects/three-risks.svg)

### 副作用 1: SSL 証明書が切れると一切アクセスできなくなる

通常なら SSL 期限切れで「警告画面を無視して進む」が選択できますが、HSTS が有効だとブラウザがそれを許可しません。期限切れ = サイト完全アクセス不能になります。

期限管理の徹底が前提です（[SSL 証明書 有効期限の確認方法](/blog/ssl-expiration-check)、[SSL 失効の業務影響](/blog/ssl-expiry-business-impact)）。

### 副作用 2: `includeSubDomains` を雑に使うと全サブドメインで事故

`includeSubDomains` を指定すると HSTS が全サブドメインに伝播します。社内ツール用のサブドメインや、HTTP でしか動かない古い検証環境まで HTTPS 強制されてアクセス不能になります。

サブドメインを把握していない状態でこの指定を入れると、想定外のサブドメインが死にます。サブドメイン棚卸しは[サブドメイン SSL は個別取得が必要？](/blog/ssl-subdomain-policy)を参照。

### 副作用 3: `max-age` を長く設定すると後戻りに時間がかかる

`max-age=31536000`（1 年）でいったん配信すると、`max-age=0` に変えても、すでにそのヘッダを受け取ったブラウザは 1 年間 HSTS を保持します。HTTPS をやめたい / ドメインを廃止したい場合に長期間動けなくなります。

`preload`（後述）まで進めると、ブラウザ側に組み込まれて削除には数ヶ月単位の申請が必要になります。

## 安全に試して恒久化する 3 段階

慎重に進めるなら、次のように段階的に強化します。

### 段階 1: 短期間 + サブドメイン除外でテスト

最初は `max-age=300`（5 分）程度から始めます。何か問題があればすぐ撤回できます。

```
Strict-Transport-Security: max-age=300
```

### 段階 2: 1 ヶ月の中期テスト

問題がなければ `max-age=2592000`（30 日）に拡大。1 ヶ月間問題なく動けば本番化候補です。

### 段階 3: 本番化（1 年 + サブドメイン含む）

最終的に `max-age=31536000; includeSubDomains` まで進めます。サブドメインを含めるのは、全サブドメインの HTTPS 化を確認してからです。

### 段階 4（任意）: HSTS preload リストへの登録

`hstspreload.org` でドメインを申請すると、Chrome / Firefox / Safari に組み込まれます。初回アクセスでも HSTS が効きますが、削除が困難な恒久措置になるため、中小企業ではほぼ不要です。登録の具体的な手続きと撤回時のリスクは [HSTS preload 登録の手続きと撤回リスク](/blog/hsts-preload-touroku-tetsuduki) で整理しています。

## まとめ

- HSTS は「HTTPS でしかアクセスさせない」をブラウザに指示する仕組み
- フォーム入力動線や自社決済 EC では導入価値が高い
- コーポレートサイト中心なら `.htaccess` 301 リダイレクトで十分なケースも多い
- 副作用は SSL 期限切れの完全アクセス不能 / サブドメイン事故 / 後戻り困難 の 3 点
- 安全に進めるなら 5 分 → 30 日 → 1 年 + サブドメイン の段階的拡張

## まずは現状を把握しましょう

自社サイトの HTTP セキュリティヘッダの状態は、ドメイン番人の[Web セキュリティヘッダ 単発チェック](/security-headers/check)で確認できます。総合点検は[無料診断](/diagnose)をご利用ください。