レスポンスヘッダー、リダイレクト、セキュリティを検査
DNS とレコード
DNS ルックアップ あらゆるドメインのすべての DNS レコード A レコードルックアップ ドメインの IPv4 アドレス AAAA レコードルックアップ ドメインの IPv6 アドレス MX ルックアップ ドメインのメールサーバー NS ルックアップ 権威ネームサーバー TXT ルックアップ TXT レコード、SPF、検証 CNAME ルックアップ 正規名（エイリアス）レコード SOA ルックアップ Start of Authority レコード SRV ルックアップ サービスロケーションレコード CAA ルックアップ どの CA が証明書を発行できるか 逆引き DNS（PTR） IP アドレスからホスト名へ DNSSEC チェック ドメインは署名され検証されているか？ DNS ヘルスチェック 委任と DNS の総合診断レポートメール到達性
SPF チェック Sender Policy Framework レコードを検証 DMARC チェック DMARC ポリシーを検査・評価 DKIM チェック DKIM 公開鍵を検索・検証 ブラックリストチェック IP をメールブロックリスト（DNSBL）と照合 SMTP テスト メールサーバーに接続し STARTTLS をチェック MTA-STS チェック 受信メールに対する強制 TLS ポリシー BIMI チェック メール用のブランドロゴレコード TLS-RPT チェック SMTP TLS レポートポリシーネットワークとウェブ
SSL 証明書チェック サイトの TLS 証明書と有効期限を検査 HTTP ヘッダーチェック レスポンスヘッダー、リダイレクト、セキュリティを検査 Ping（TCP） TCP 経由での到達性と遅延 ポートチェック どの一般的なポートが開いているかドメイン
WHOIS ルックアップ ドメイン、IP、ASN の登録データHTTPレスポンスヘッダーは、ウェブサーバーの挙動を明らかにします。返すステータスコード、リダイレクト先、稼働ソフトウェア、送信するセキュリティ強化ヘッダーなどです。HSTS、Content-Security-Policy、X-Frame-Optionsといったヘッダーが欠けていると、サイトはダウングレード攻撃、インジェクション攻撃、クリックジャッキング攻撃にさらされます。IPeekはリダイレクトチェーン全体をたどり、主要なセキュリティヘッダーに照らしてレスポンスを評価します。
すべてのHTTPレスポンスは、ページ本文の前にステータスコードと一連のヘッダーから始まります。ステータスコードは何が起きたかをクライアントに伝えます。200は成功、301と302はリソースの移動、404は未検出、5xxはサーバーの失敗を意味します。ヘッダーは、Content-Type、Server、Cache-Controlや、ブラウザにページの扱い方を指示するセキュリティディレクティブなどのメタデータを運びます。IPeekはURLにリクエストを送り、サーバーが送信したとおりに正確にこれらのヘッダーを取得し、各リダイレクトをたどることで、最終レスポンスまでの完全な経路を見せます。
まず最終ステータスコードが期待どおりか、通常は稼働ページなら200かを確認します。次にリダイレクトチェーンをたどります。きれいな設定では、HTTPからHTTPSへ、非正規ホストから正規ホストへと、できるだけ少ないホップでリダイレクトします。余分なリダイレクトはすべて遅延を増やすからです。リダイレクトループや、誤ったホストに着地するチェーンに注意してください。Serverヘッダーは使用ソフトウェアを明かし、セキュリティヘッダーの評価は、どの保護ヘッダーが存在し、どれが欠けているかを一目で示します。
Strict-Transport-Security（HSTS）はブラウザにHTTPSの使用を強制し、ダウングレード攻撃を防ぎます。Content-Security-Policyはスクリプトやリソースの読み込み元を制限し、クロスサイトスクリプティングに対する最強の防御です。X-Frame-OptionsまたはCSPのframe-ancestorsディレクティブは、誰がページを埋め込めるかを制御してクリックジャッキングをブロックします。X-Content-Type-Options: nosniffはMIMEスニッフィングを止めます。最もよくある欠落は、これらを一切配信しないサイトで、ブラウザに追加の保護がない状態を残します。ウェブサーバーまたはCDNで追加し、稼働中のレスポンスに現れるか再確認してください。
デプロイ後、CDNやリバースプロキシの変更後、サイトのセキュリティ態勢を強化したときにヘッダーをチェックしてください。これらはヘッダーが追加・削除・上書きされる瞬間だからです。HTTPからHTTPSへのリダイレクトが実際に機能しているか確認したり、予期しないリダイレクトチェーンをデバッグしたり、設定したセキュリティヘッダーが配信経路のどこかで剥がされず実際のブラウザに届いているか検証したりする最速の方法です。
サイトが返すステータスコード、リダイレクトチェーン、サーバーソフトウェア、セキュリティヘッダーが分かります。URLが正しくリダイレクトするか、何ホップかかるか、どのサーバーが応答しているか、HSTSやContent-Security-Policyのような保護ヘッダーが存在するか欠けているかが分かります。そのため、ルーティングの問題とセキュリティの欠落の両方を素早く診断できます。
HTTP Strict-Transport-Securityは、一定期間ブラウザにHTTPSでのみ接続するよう指示するヘッダーです。攻撃者が安全でないHTTP接続を強制するダウングレード攻撃や中間者攻撃を防ぐため重要です。ブラウザは一度HSTSを認識すると、ポリシーが期限切れになるまでそのホストへの平文HTTPを拒否し、実際の攻撃の機会を封じます。
リダイレクトチェーンは、別々のルールがそれぞれ1つの問題を修正するときに積み重なりがちです。HTTPからHTTPSへ、非wwwからwwwへ、末尾スラッシュの正規化などです。各ホップは遅延とエラーの可能性を増やします。可能なら、最終的な正規URLへの単一のリダイレクトにまとめ、2つのルールがリクエストを行き来させるループに注意してください。
最低限、Strict-Transport-Security、Content-Security-Policy、X-Content-Type-Options: nosniff、そしてX-Frame-OptionsまたはCSPのframe-ancestorsによるフレーム保護を送信してください。HSTSはHTTPSを強制し、CSPはスクリプトインジェクションを制限し、nosniffはMIMEの混同を止め、フレーム保護はクリックジャッキングをブロックします。これらを組み合わせれば、サーバーまたはCDNで一度設定するディレクティブで、最も一般的なブラウザ側の攻撃クラスをカバーできます。
301は恒久的リダイレクト、302は一時的リダイレクトです。301はリソースが恒久的に移動したことをブラウザと検索エンジンに伝えるため、ブックマークが更新され、ランキングシグナルが新しいURLへ引き継がれます。302は移動が一時的であると伝えるため、クライアントは元のURLを使い続けます。正規化やHTTPSのリダイレクトには301を使ってください。