HTTPSとは

詳細な図解

HTTPSを読むときの前提

HTTPS（HTTP Secure）は、HTTPをTLSで保護した通信です。利用者から見ると鍵マークやURLのschemeとして見えますが、実際には証明書、TLS設定、リダイレクト、HSTS、CDN、混在コンテンツが関係します。

実務では、HTTPからHTTPSへの誘導、証明書、TLS終端点、外部リソース、Cookie属性、HSTS、オリジンとの通信方式を確認します。

証跡には、URL、HTTPステータス、リダイレクト先、証明書、TLSバージョン、HSTSヘッダー、混在コンテンツ有無、確認日時を残します。

リダイレクトと終端点を確認する

HTTPS化は、証明書を入れるだけでは完了しません。HTTPアクセスをどこでHTTPSへ誘導するか、CDNやロードバランサーでTLSを終端するか、オリジンまでHTTPSにするかを決めます。

リダイレクトループ、www有無、末尾スラッシュ、APIパス、管理画面だけ別終端といった差分があると、一部URLだけ失敗します。

• HTTPからHTTPSへの応答を確認する。
• CDN/LB/オリジンの終端点を整理する。
• 代表URLだけでなくAPIや管理画面も見る。

混在コンテンツとCookieを見る

ページ本体がHTTPSでも、画像、CSS、JavaScript、iframe、API呼び出しがHTTPのままだと、ブラウザがブロックしたり警告を出したりします。HTTPS化後の表示崩れでは混在コンテンツを確認します。

認証やセッションを扱う場合は、CookieのSecure、HttpOnly、SameSiteも確認します。HTTPSにしてもCookieが平文経路へ出る設定なら守りが弱くなります。

• ブラウザ開発者ツールで混在コンテンツを確認する。
• 外部リソースのschemeを確認する。
• Cookie属性を確認する。

HSTSは戻しにくさを考える

HSTSを有効にすると、ブラウザは以後HTTPではなくHTTPSへ自動的に接続します。セキュリティは強くなりますが、証明書やHTTPS配信に問題があると利用者が回避しにくくなります。

includeSubDomainsやpreloadを使う場合は、サブドメイン、検証環境、外部サービス、古いHTTP専用ホストまで影響を確認します。

• HSTSのmax-ageを段階的に伸ばす。
• サブドメイン影響を確認する。
• preload申請前に戻し手順を確認する。

変更証跡と引き継ぎ

HTTPS対応では、対象URL、リダイレクトルール、証明書、TLS終端点、HSTS、混在コンテンツ、Cookie属性、確認ブラウザを残します。Web、DNS、CDN、アプリの境界をまたぐためです。

引き継ぎでは、関連語としてHTTP、TLS、証明書、HSTS、Cookieを残すと、表示不具合とセキュリティ設定を同じ流れで追えます。

• 代表URLの確認結果を保存する。
• HTTP/HTTPSの応答差分を記録する。
• HSTSとCookie設定を変更管理に含める。

関連語

同じ主要カテゴリの用語

セキュリティ・認証の学習順

同じ主要カテゴリの用語をまとめて確認できます。現在の用語を起点に、前後の用語へ進むと文脈を保ったまま読み進められます。

InfraEngKit内の関連機能