ドメイン番人
Web セキュリティHSTSWeb 担当者How-to

HSTS の設定方法｜Cloudflare / Nginx / WordPress 別の手順

ドメイン番人約 6 分で読めます
目次

この記事でわかること

  • HSTS（Strict-Transport-Security）が「初回 HTTPS 後は HTTP に戻れない」を強制する仕組みであること
  • Cloudflare / Nginx / WordPress（.htaccess）別の具体的な設定手順
  • preload 申請の前提と、安易に申請しない方が良い理由
  • 事故を防ぐための短期 max-age 検証フロー

HSTS は「ブラウザに HTTPS を強制させる」仕組み

HSTS（HTTP Strict Transport Security、RFC 6797）は、Web サーバーがレスポンスヘッダで「このドメインは max-age 秒間、必ず HTTPS で接続して」と宣言する仕組みです。

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

ブラウザはこの指示をローカルに記憶し、以降は http://... をユーザーが入力しても、サーバーに到達する前に強制的に https://... に書き換えます。

HSTS の動作の仕組み

これにより:

  • 中間者攻撃で HTTP に降格させようとするリダイレクトが効かない
  • 公衆 Wi-Fi 等の経路上で HTTP 通信を盗み見られない
  • HTTPS 必須のサイトで「うっかり http:// のリンクから入る」事故が起きない

Cloudflare での設定（最も簡単）

Cloudflare の管理画面から GUI で設定可能。サーバー側のコード変更は不要。

手順

  1. Cloudflare ダッシュボード → 対象ドメイン
  2. SSL/TLS → Edge Certificates へ
  3. HTTP Strict Transport Security (HSTS) セクションで Enable HSTS をクリック
  4. 設定:
    • Max Age Header (max-age): 12 months（31,536,000 秒）
    • Apply HSTS policy to subdomains: オン（includeSubDomains）
    • Preload: オン（後述）
    • No-Sniff Header: オン（X-Content-Type-Options: nosniff も同時に有効化）

所要 1 分。Cloudflare のエッジで自動的にヘッダ付与されます。

Nginx での設定

サイト設定ファイルに 1 行追加します。

server {
    listen 443 ssl;
    server_name example.co.jp;

    # 他の設定 ...

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

ポイント

  • always 引数: 4xx / 5xx エラー応答にもヘッダを付与する。always が無いと Nginx は限られた応答コード（200 / 201 / 204 / 206 / 301 / 302 / 303 / 304 / 307 / 308）にしかヘッダを付けないため、エラーページから HSTS が抜けて HTTP 降格を許す原因になる
  • 設定後 nginx -t で構文確認 → nginx -s reload で反映
  • 複数の server ブロックがある場合は全てに追加

WordPress（Apache + .htaccess）での設定

WordPress の場合は .htaccess か functions.php で設定します。

.htaccess で設定する場合（推奨）

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

mod_headers モジュールが有効である必要があります。多くのレンタルサーバーは標準で有効です。

プラグインで設定する場合

.htaccess の編集が難しい環境（管理画面からのアクセスのみ等）では、以下のプラグインで GUI 設定できます:

  • HTTP Headers: 各種セキュリティヘッダを GUI 設定
  • Really Simple SSL: HTTPS 化と HSTS をワンセットで設定

ただしプラグインに依存すると、プラグイン削除時にヘッダも消える点に注意。

サーバー別の HSTS 設定方法

事故を防ぐ「短期 max-age」検証フロー

HSTS の最大の落とし穴は、一度設定すると max-age 期間中は撤回が困難な点です。証明書の更新ミスや HTTPS 設定の不備があった場合、ブラウザが頑なに HTTPS を要求し続けるため、warning 画面のまま操作不能になります。

推奨フロー

  1. Day 0: max-age=86400（1 日）で設定して動作確認 
    Strict-Transport-Security: max-age=86400
  2. Day 1〜7: 主要ブラウザ・モバイル等で全画面の表示確認
  3. 問題なし: max-age=2592000（30 日）に上げて様子見
  4. Day 30 以降: max-age=31536000（1 年）に拡大、includeSubDomains 追加
  5. 必要なら: preload 申請（次節）

includeSubDomains の罠

includeSubDomains を入れると、*.example.co.jp の全サブドメインにも HSTS が適用されます。

  • メインは HTTPS 化済みだが、legacy.example.co.jp がまだ HTTP のみ → サブドメインへのアクセスがブロックされる
  • マーケ部門が独自に立ち上げたサブドメインで証明書がない → 同様

事前に 保有サブドメインを全棚卸ししてから includeSubDomains を入れるのが安全です。

preload 申請の前提

preload ディレクティブを付け、hstspreload.org で申請すると、Chrome 等の主要ブラウザに初回アクセスの前から HSTS 強制が焼き込まれます。新規ユーザーや「履歴を消した」ユーザーにも HSTS が効きます。

申請の前提条件

  • 有効な SSL 証明書が設定されている
  • HTTP（80 番）から HTTPS（443 番）への 301 リダイレクトが設定済み
  • すべてのサブドメインで HTTPS が動いている（includeSubDomains 必須）
  • max-age が 31,536,000 秒（1 年）以上
  • preload ディレクティブ付き

申請後の解除は半年〜1 年以上かかる

申請後にブラウザに焼き込まれるため、後で「やっぱり HSTS を外したい」と思っても、すべての主要ブラウザのリストから消えるまで時間がかかります。本当に永続的に HTTPS 必須にするドメインだけ申請しましょう。具体的な登録手続きと撤回時のリスクは HSTS preload 登録の手続きと撤回リスク で解説しています。

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

自社サイトの HSTS 設定状況（max-age / includeSubDomains / preload 適格性）は、ドメイン番人の Web セキュリティヘッダ 単発チェック で 30 秒で確認できます。

HSTS の安全な段階導入（短期 max-age での検証 → 拡大 → preload 申請判断）のスポット支援は Web セキュリティヘッダ診断＋設定支援（3 万円〜）でご相談いただけます。

他社チェッカー（securityheaders.com / Mozilla Observatory）との違いは Web セキュリティヘッダのチェッカー比較 を参照してください。

CSP の入門は CSP（Content-Security-Policy）とは？Web 担当者のための入門、ブラウザ機能（カメラ / マイク / 位置情報）の制限は permissions-policy で機能を制限する設定 を参照してください。メール認証や SSL も含めた総合点検は 無料のドメイン診断 を、SSL 単独の確認は SSL 単発チェック をご利用ください。

関連記事

次の一歩は無料診断から。

無料診断を試す →相談したい方はこちらから