Defaults.Exposed › 修正 › HSTS（Strict-Transport-Security）

HSTS（Strict-Transport-Security） の直し方

HSTSは、ウェブサイトがすべてのブラウザに与える1行の指示です。『常に安全な暗号化接続で戻ってきて、決して安全でないほうは使わないで』。これがないと、共有Wi-Fiで鍵マークが静かに剥がされ、サイトへの最初の訪問が露出します。

あなたのビジネスにとっての結論： HTTPS（鍵マーク）を持つことと、それを強制することは別です。HSTSがないと、顧客と同じWi-Fiにいる攻撃者が接続を平文の暗号化されていないHTTPへ静かに引き下げ、ログイン・カード情報・フォームデータを捕らえます。顧客には何も異常が見えません。お金を払っているかもしれないSSL証明書が回避されます。修正は無料で、サイトを運用する人にとって15分ほどです。

これで失いかねないもの

• カフェ・ホテル・空港・会議場のWi-Fiにいる顧客は、サイトへの接続を静かに引き下げられ、画面に警告も出ないままデータを読まれることがあります。
• HTTPSにお金を払い鍵マークもあるのに、HSTSがないと攻撃者はそれを単に迂回できます。証明書が偽りの安心感を与えます。
• サイトへの最初の訪問（HTTPSへのリダイレクト前）が攻撃者の狙う弱点で、HSTSはそれをすべての再訪問について閉じるものです。
• セキュリティ質問票・サイバー保険のフォーム・大企業の買い手のチェックリストが『HSTSなし』を指摘し、修正されるまで商談が止まります。
• 値を間違える（短すぎる）と両者のいいとこ取りを失います。設定済みに見えるのに、実質的にほとんど保護がありません。

なぜ重要か。 HTTPSは接続がいったん暗号化されれば守りますが、ブラウザにそれを使うよう強制はしません。攻撃者は『SSLストリッピング』でそのギャップを突き、どの共有ネットワークでも訪問者を安全でないHTTPに静かに留め、すべてを読みます。HSTSはあなたのドメインの平文HTTPを完全に拒否するようブラウザに長期間指示し、最初の訪問の後にギャップを閉じます。これはひとつのレスポンスヘッダーで、追加は無料、当社の採点では相応の点に値します。欠けている・短すぎる値は、公衆Wi-Fi上のすべての訪問者を露出させるからです。

これは何か、平易に言うと

あなたはほぼ確実にHTTPS—ブラウザバーの小さな鍵マーク—を持っています。結構です。でも、ほとんど誰も教わらない部分があります。HTTPSを持つことと、それを強制することは別です。

HTTPSはブラウザが使うと決めたときに接続を暗号化します。HSTS—HTTP Strict Transport Securityの略—は、ブラウザに常にそれを使わせる指示です。サイトがすべての訪問者に送る、目に見えない1行で、実質的にこう言います：

「今から、私のドメインについては、常に安全な接続でのみ話して。決して安全でないほうではなく。試みることすらしないで。」

ブラウザはそれを覚え、指定した期間—通常1年—従います。訪問者の最初の安全な訪問の後、ブラウザは何かが強制しようとしても、あなたのサイトを平文の暗号化されていないHTTPで読み込むことを単に拒否します。

HSTSがないと、その『常に安全な版を使う』ルールが存在せず—攻撃者はそのギャップの突き方を正確に知っています。

これが招きうる損失

これらは現実的で日常的な筋書きです。当社は実在の企業名を挙げることはありません。これらはギャップがどう使われるかの例示です。

1. カフェの決済。 顧客がカフェのWi-Fiであなたの店を開き、決済へ進みます。同じネットワーク上の攻撃者が、無料で有名なツールを使って顧客をHTTPSではなく平文HTTPに留めます。顧客には普通のサイトに見えるもの—警告も、ちらっと見る場所の壊れた鍵マークもなし—が見え、カード情報を入力します。攻撃者はすべてのキー入力を読みます。あなたのSSL証明書は何もしませんでした。そもそも接続が安全になることを許されなかったからです。

2. 出張中の社員。 社員がホテルや空港から管理パネルやウェブメールにログインします。同じ引き下げの手口でユーザー名とパスワードが捕らえられます。今や攻撃者はあなたのビジネスへの入り口を手にしました—パスワードポリシーが弱かったからではなく、ログインページが安全でないHTTPで到達できたからです。

3. 止まる商談。 大口顧客が契約前に標準のセキュリティ質問票を送ってきます。1行にこうあります：『あなたのウェブサイトはHSTSでHTTPSを強制していますか？』IT担当者は『いいえ』と答えるしかなく、無料で15分の設定—今や買い手の前で危険信号に見える—を慌てて直す間、調達プロセスが止まります。

4. サイバー保険やコンプライアンスのチェック。 保険会社のスキャン、またはデータ保護態勢を見る監査人が、欠けているヘッダーを指摘します。個人データの暗号化はデータ保護規則（GDPR第32条）の明示的な期待であり、『証明書はあるが強制していない』は立っていて弱い場所です。

5. 偽りの安心感。 SSLにお金を払い、鍵マークが出て、皆がサイトは安全だと思い込みます。たいていは安全です—顧客が共有ネットワークにいるときを除いて。それがまさに最も脆弱で、何かおかしいと気づきにくいときです。

一貫した筋書き：コストは抽象的ではありません。実在する顧客のカードやログインが、最悪のタイミングで、何の警報も鳴らずに捕らえられるのです。

これの実体

ブラウザがウェブサイトにページを求めると、サーバーはページに加えて目に見えない『ヘッダー』—ブラウザが読むが訪問者は決して見ない追加の指示—を返します。HSTSはそのヘッダーのひとつです：

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

3つの部分が重要です：

• max-age — ブラウザがHTTPSの強制を覚えておく期間（秒）。31536000は1年。これが核心です。短すぎるとほとんど役立ちません。
• includeSubDomains — ルールをすべてのサブドメイン（shop.、app.、mail.など）に拡張します。主アドレスだけではなく。
• preload — あなたのドメインをブラウザに組み込まれたマスターリストに登録し、訪問者がまだサイトを見たことのないごく最初のリクエストにも保護を適用します。

なぜ『最初の訪問』が重要か

HSTSには固有の限界がひとつあります。ブラウザはルールを少なくとも一度ヘッダーを見た後にのみ従います。だからまったく新規の訪問者のごく最初の接続は依然として小さな露出の隙間です。2つがそれを狭めます。HTTPからHTTPSへのリダイレクト（素早く安全な版に乗せる）とpreload（隙間を完全になくす）です。だから完全な構成はHSTSを適切なリダイレクトと組み合わせます。

『良い』状態とは—採点はどうなるか

当社の検査はライブのヘッダーを読み、max-ageを採点します：

つまり、存在するが数分に設定されたヘッダーは不合格として扱われます—設定済みに見えても仕事をしていないからです。1年を目指してください。検査はincludeSubDomainsとpreloadがあるかも記録します。

修正方法（無料・約15分）

ウェブサイトを運用している人—IT担当、ウェブ開発者、ホスティングのサポート—にこの項を渡してください。修正は無料です。 ひとつのヘッダー、またはホスティングプラットフォームの切り替えです。買うものはありません。

まずひとつ重要な順序ルール： HSTSは粘着的です—一度有効にすると、ブラウザはmax-ageの全期間、あなたのドメインの平文HTTPを拒否します。だから、広くオンにする前に、主サイトとすべてのサブドメインでHTTPSが正しく機能していることを確認してください。安全な道は：短い値でテスト → 何も壊れないことを確認 → 1年に上げるです。

ステップ1 — HTTPSがすでにどこでも機能していることを確認する

サイトと主要なサブドメインをhttps://で訪れ、有効な証明書できれいに読み込まれることを確認します。また平文http://のリクエストがhttps://へリダイレクトされることも確認します。（されていなければ、まずHTTPからHTTPSへのリダイレクトを直してください—HSTSはそれがあることを前提とします。）

ステップ2 — ヘッダーを追加する（プラットフォームを選ぶ）

Cloudflare（または同様のCDN）： これが最も簡単。SSL/TLS → Edge Certificates → HTTP Strict Transport Security (HSTS) へ行き有効にします。Max-Ageを6か月か12か月に設定し、すべてのサブドメインがHTTPSになっていると確信したら『Apply HSTS policy to subdomains』を有効にします。

Nginx： HTTPSのserverブロック内に追加：

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

Apache： mod_headersが有効であることを確認し、HTTPSの仮想ホストに追加：

Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"

Microsoft IIS： web.configの<customHeaders>内に追加：

<add name="Strict-Transport-Security" value="max-age=31536000; includeSubDomains; preload" />

Google Workspace / Microsoft 365 についての注記： これらはあなたのメールを動かすもので、ウェブサイトのホスティングではありません—HSTSは公開ウェブサイトが実際にある場所（CDN、ウェブサーバー、サイトビルダー）で設定し、Workspace/365の管理画面では設定しません。サイトがSquarespace・Wix・Shopifyのようなビルダーにあるなら、HSTSはたいてい任せられています。当社の検査が指摘したら、そのSSL／セキュリティ設定を確認してください。

ステップ3 — 小さくテストし、それからコミットする

max-age=300（5分）で始めます。サイトがどこでも完璧に読み込まれることを確認します。それからmax-age=31536000（1年）に上げます。それが満点の設定です。

ステップ4（任意、最高水準）— preload

自信を持ち、includeSubDomains付きの1年のヘッダーをしばらく運用したら、hstspreload.orgでドメインを送信し、ブラウザに焼き込めます。これで最初の訪問の隙間が完全に閉じます。意図的なコミットメントとして扱ってください—リストからドメインを外すのは遅いです。

よくある間違い

• max-ageを短くしすぎる。 数分や数時間の値は設定済みに見えてほとんど保護を与えず、当社の検査は1日未満を不合格として扱います。1年を使いましょう。
• サブドメインがHTTPS対応になる前にincludeSubDomainsをオンにする。 サブドメインが完全にHTTPSでないと、粘着ルールが訪問者にとってそれを到達不能にしかねません。まずすべてのサブドメインをHTTPSにしてください。
• HSTSを追加するがHTTPからHTTPSへのリダイレクトがない。 HSTSは訪問者が安全な版に到達することを前提とします。リダイレクトがなければ最初の訪問が無用に露出します。両方を一緒に直しましょう。
• 『徹底するため』にいきなりpreloadへ飛ぶ。 preloadは取り消しにくい。安定した1年のヘッダーの後、徐々に得るものです—急がないこと。
• 鍵マークでカバーされていると思い込む。 鍵マークとHSTSは別物です。完璧な証明書を持っていても、この検査に落ちることはあります。

よくある質問