どうも、PHPをかれこれ20年近く触っているベテランエンジニアです。最近、後輩から「サイトのセキュリティって、SSL化（HTTPS）してれば、とりあえず安心なんですよね？」なんて、キラキラした目で聞かれましてね。いや、気持ちはわかる。わかるんだけど、実はそれだけじゃ甘いんだな、これが。
昔、フリーWi-Fiが珍しかった頃、出先のカフェでドヤ顔でノートPC広げて作業してたら、どうも挙動がおかしい。ログインしようとしても弾かれるし、なんだか妙に通信が遅い。後でわかったんですが、まんまと通信を横取りされてたんですよね。幸い、大事な情報が抜かれる前に気づいたから良かったものの、あの時の「サーっ」と血の気が引いていく感覚は、今でも忘れられません。
実は、SSL化して鍵マークがついていても、最初の「こんにちは！」の挨拶（最初の接続リクエスト）が暗号化されていない「HTTP」だと、その隙を狙って悪意のある第三者が割り込んでくることがあるんです。これを「中間者攻撃（Man-in-the-Middle Attack）」って言います。特に、SSLストリッピングっていう攻撃は巧妙で、ユーザーは気づかないうちに偽のサイトに誘導されて、IDやパスワードを根こそぎ持っていかれるなんてことも…。
そこで登場するのが、今回の主役「HSTS（HTTP Strict Transport Security）」です。こいつを導入しておけば、ブラウザに対して「このサイトは、絶対にHTTPSでしか通信しちゃダメだからな！」って、強く命令してくれるんです。一度この命令を受け取ったブラウザは、たとえユーザーが間違って「http://」でアクセスしようとしても、自動的に「https://」に切り替えてくれる。つまり、中間者攻撃が入り込む隙を最初からなくしてしまう、というわけです。
今回は、この「HSTS」っていう、ちょっと強面だけど頼りになる用心棒を、あなたのWordPressサイトに導入する方法を、できるだけ分かりやすく、実践的に解説していこうと思います。セキュリティ対策は、やりすぎってことはありませんからね。一緒にサイトの守りを固めていきましょう。
なんで「SSL化だけ」じゃダメなのか？中間者攻撃の怖い話
「HTTPSになってるから大丈夫っしょ！」って思ってる、そこのあなた。その考え、ちょっと危険かもしれません。なぜなら、攻撃者は僕らが思っているよりもずっと賢くて、あの手この手で情報を盗もうと狙っているからです。
見えないところで通信が裸にされる「SSLストリッピング」
中間者攻撃の中でも特に厄介なのが、「SSLストリッピング」です。これは、ユーザーとサーバーの間に攻撃者が割り込んで、HTTPS通信を強制的に暗号化されていないHTTP通信に引きずり下ろす（ダウングレードさせる）攻撃です。
具体的に何が起こるかというと…
- 最初の挨拶を横取り：あなたがカフェのフリーWi-Fiを使って、あるサイトに「http://」でアクセスしようとします。（ブラウザのアドレスバーにURLを直接入力したり、古いブックマークから飛んだりすると、こうなることがあります）
- 攻撃者が割り込む：そのリクエストを、同じWi-Fiを使っている攻撃者がキャッチします。
- なりすまし通信：攻撃者は、あなたになりすまして、本来のサーバーと「https://」で通信を始めます。
- 偽の応答：そして、あなたには「http://」のまま、偽のページを返します。見た目は本物のサイトと全く同じなので、あなたは全く気づきません。
- 情報だだ漏れ：あなたがその偽ページでIDやパスワードを入力すると、その情報は暗号化されずに攻撃者に筒抜け。攻撃者はその情報を使って、本物のサーバーにログインできてしまう、というわけです。
恐ろしいのは、あなたのブラウザのアドレスバーには鍵マークが表示されず、URLも「http://」のままなのに、見た目が全く同じなので、ほとんどの人は攻撃されていることに気づけない、という点です。まさに、知らない間に丸裸にされているような状態ですね。
HSTSが「用心棒」になる仕組み
ここでHSTSの出番です。HSTSは、一度でもサイトにHTTPSでアクセスしたブラウザに対して、「Strict-Transport-Security」という特別なメッセージ（レスポンスヘッダー）を送ります。このメッセージには、「今後、〇〇日間は、絶対にHTTPSでしか接続するな！」という命令が書かれています。
この命令を受け取ったブラウザは、律儀にそのサイトを「HTTPS専用サイト」として記憶します。だから、次回以降、たとえあなたが「http://」でアクセスしようとしても、ブラウザが「ダメダメ、このサイトはHTTPSじゃないと！」と、自動的に「https://」に書き換えてから接続しに行ってくれるんです。
つまり、攻撃者が最初の「http://」でのアクセスを横取りしようとしても、その機会自体がなくなる。これがHSTSが中間者攻撃に強い理由です。頼りになる用心棒だと思いませんか？
WordPressにHSTSを導入する3つの方法
さて、理屈がわかったところで、いよいよ実践です。WordPressにHSTSを導入するには、大きく分けて3つの方法があります。あなたのサイトの環境やスキルレベルに合わせて、最適な方法を選んでみてください。
方法1：.htaccessファイルを編集する（基本にして王道）
多くのレンタルサーバー（ApacheというWebサーバーを使っている場合）で使える、最も基本的な方法です。サーバーの設定ファイルを直接いじるので、少し緊張するかもしれませんが、コピペでいけるので安心してください。ただし、作業前には必ずバックアップを取得すること！ これ、絶対のお約束です。
- FTPソフトか、サーバーのファイルマネージャーに接続します。
- WordPressをインストールした一番上の階層（
wp-config.phpとかがある場所）にある、.htaccessというファイルを探します。 - この
.htaccessファイルをダウンロードして、テキストエディタで開きます。 - ファイルの一番下に、以下のコードを追記します。
<ifModule mod_headers.c>
Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" env=HTTPS
</ifModule>- ファイルを保存して、サーバーの元の場所に上書きアップロードします。
これだけです。簡単でしょ？
コードの中身を少しだけ解説すると…
max-age=31536000: HSTSを有効にする期間を秒単位で指定します。31536000秒はちょうど1年です。最初は短め（例えばmax-age=600とか）でテストして、問題なければ長くするのがおすすめです。includeSubDomains: サブドメイン（例:blog.example.com）にもHSTSを適用する、という命令です。サブドメインがないなら不要ですが、あっても困ることはないので、入れておくのが一般的です。preload: 後述する「プリロードリスト」に申請するための記述です。最初はこれなしでテストしてもOKです。
注意！ この作業をミスると、サイトが真っ白（500エラー）になることがあります。その時は慌てず、追記したコードを削除した.htaccessを再度アップロードすれば元に戻ります。だからこそ、バックアップは命綱なんです。
方法2：プラグインを使う（お手軽だけど注意も必要）
「サーバーのファイルを直接いじるのは、やっぱり怖い…」という方には、プラグインを使う方法もあります。「Headers Security Advanced & HSTS WP」や「Really Simple SSL」のPro版などが有名ですね。
ポチポチっと設定画面で有効にするだけでHSTSを導入できるので、非常に手軽です。ただ、プラグインは手軽な反面、他のプラグインとの相性問題や、プラグイン自体の脆弱性というリスクもゼロではありません。個人的には、サーバーの設定でできることは、なるべくサーバー側で対応する方が、サイトの動作も軽快になるので好きですね。
方法3：CDNサービス（Cloudflareなど）の設定を使う
CloudflareのようなCDN（コンテンツ・デリバリー・ネットワーク）サービスを使っているなら、その管理画面からHSTSを有効にできることが多いです。これも数クリックで設定できるので、めちゃくちゃ楽です。
Cloudflareの場合、管理画面の「SSL/TLS」→「エッジ証明書」のタブに、「HTTP Strict Transport Security (HSTS)」という項目があります。ここからポチッと有効にするだけ。
すでにCDNを導入しているなら、これが一番簡単で安全かもしれませんね。
さらにセキュリティを強化する「プリロードリスト」とは？
HSTSには、実は一つだけ弱点があります。それは、「一度HTTPSでアクセスしないと、HSTSの命令がブラウザに伝わらない」という点です。つまり、生まれて初めてそのサイトにアクセスする時だけは、中間者攻撃のリスクが残ってしまうんです。
この最後の穴を埋めるのが、「HSTSプリロードリスト」です。
これは、Googleが中心となって管理している「HSTSが有効なサイトのリスト」で、ChromeやFirefox、Safariなどの主要なブラウザに、あらかじめ組み込まれています。このリストにあなたのサイトが登録されると、ユーザーが一度もアクセスしたことがなくても、ブラウザは「あ、このサイトはHTTPS専用だな」と知っているので、最初からHTTPSで接続しに行ってくれるんです。
プリロードリストに申請する方法
申請は、公式サイト「HSTS Preload List Submission」から行います。
サイトのドメインを入力して、「Check HSTS preload status and eligibility」ボタンを押すだけ。ただし、申請にはいくつか条件があります。
- 有効なSSL証明書が設定されていること。
- サイト全体がHTTPSにリダイレクトされること。
- HSTSヘッダーの
max-ageが最低でも31536000（1年）であること。 - HSTSヘッダーに
includeSubDomainsとpreloadディレクティブが含まれていること。
先ほど紹介した.htaccessのコードは、この条件を満たすように書いてあります。
プリロードの注意点：後戻りはできない！
プリロードリストへの登録は、セキュリティを最大限に高める強力な手段ですが、一つだけ大きな注意点があります。それは、一度登録されると、リストからの削除が非常に難しいということです。
もし、何らかの理由で「サイトの一部をHTTPに戻したい」とか、「SSL証明書の更新をうっかり忘れた！」なんてことになると、プリロードリストに登録されているサイトは、ブラウザがHTTPSでの接続を強制するため、サイトが全く表示されなくなってしまいます。
なので、プリロードリストへの申請は、「今後、未来永劫、このドメイン全体をHTTPSで運用し続けるぞ！」という固い決意が固まってからにしましょう。個人的には、まずはプリロードなしでHSTSを1年くらい運用してみて、問題がなければ申請を検討する、というステップを踏むのが安全だと思います。
FAQ：よくある質問
ここで、HSTSに関してよく聞かれる質問に、いくつか答えておきますね。
Q1. HSTSを設定したら、サイトの表示が速くなるって本当？
A. はい、わずかですが速くなる可能性があります。HSTSが有効だと、HTTPからHTTPSへのリダイレクト処理（301リダイレクト）をサーバーに問い合わせる前に、ブラウザ側で完結させてくれるからです。ユーザー体験の向上にも、ほんの少し貢献してくれます。
Q2. SEOに影響はありますか？
A. 良い影響はあっても、悪い影響は基本的にありません。GoogleもHSTSの使用を推奨していますし、セキュリティが強固であることは、検索順位においてもプラスに評価される傾向にあります。安心して導入してください。
Q3. 導入後にエラーが出たらどうすればいい？
A. まずは、ブラウザのキャッシュをクリアしてみてください。それでもダメなら、ブラウザのHSTS設定をリセットする必要があります。Chromeなら、アドレスバーにchrome://net-internals/#hstsと入力して、表示された画面下部の「Delete domain security policies」でドメインを指定して削除できます。ただ、これは一時的な対処なので、根本的な原因（.htaccessの記述ミスなど）を解決する必要があります。
Q4. サブドメインだけHTTPで使いたい場合はどうすればいい？
A. その場合は、HSTSヘッダーからincludeSubDomainsを外す必要があります。これを付けたままHSTSを導入すると、サブドメインも強制的にHTTPS化されてしまうので、注意が必要です。プリロードリストへの申請も、もちろんできません。
Q5. HSTSが正しく設定されているか確認する方法は？
A. Chrome DevToolsを使うのが一番簡単です。サイトを開いた状態で、F12キーを押して開発者ツールを開き、「Network」タブを選択。ページをリロードして、一番上のリクエストをクリック。「Headers」の中の「Response Headers」にStrict-Transport-Securityという項目があれば、HSTSが有効になっています。オンラインツール「Security Headers」でチェックするのもおすすめです。URLを入力するだけで、HSTSを含む各種セキュリティヘッダーの設定状況を一発で確認できます。
まとめ：HSTSは、もはや「やって当たり前」のセキュリティ対策
今回は、HSTSによる中間者攻撃対策について、かなり突っ込んで解説してみました。ちょっと専門的な話も多かったかもしれませんが、要点は以下の通りです。
- SSL化（HTTPS）だけでは、中間者攻撃のリスクはゼロにならない。
- HSTSは、ブラウザにHTTPS接続を強制させることで、そのリスクを大幅に減らせる。
- 導入は
.htaccessの編集が基本。プラグインやCDNでも可能。 - さらに強力な「プリロードリスト」もあるが、導入は慎重に。
20年前、僕がこの業界に入った頃は、SSL証明書自体が高価で、一部のECサイトくらいしか導入していませんでした。でも今は、無料で使えるSSL証明書も普及し、常時SSL化は当たり前。そして、その一歩先を行くHSTSも、もはや「やってて当然」のセキュリティ対策になりつつあります。
あなたのWordPressサイトを、そしてそのサイトを訪れてくれるユーザーを、見えない脅威から守るために。この記事が、あなたのサイトの守りを一段と固めるきっかけになれば、エンジニアとしてこれほど嬉しいことはありません。
WordPressのセキュリティ、不安に思っていませんか？
「設定はしたけど、本当にこれで安全なのかな…」
「最近、サイトの動きがなんだか重い気がする…」
そんな不安をお持ちなら、一度プロの目であなたのサイトをチェックしてみませんか？
WordPressセキュリティ診断サイトでは、あなたのサイトに潜む脆弱性を専門家が徹底的に洗い出し、具体的な改善策をレポートします。手遅れになる前に、ぜひ一度ご相談ください。
【フッター画像：WordPressセキュリティ診断サイトのバナー】
