01
URLと実行時点を確認
ドメイン名だけならHTTPSを補います。例を選んでも通信は始まらず、確認ボタンを押したときだけ対象へアクセスします。
HTTP・リクエスト調査
HTTPヘッダー確認
公開URLの最初の応答を調べる
HTTPヘッダー確認
公開URL
応答レポート
公開URLを入力し、手動で確認してください。
URLは当サイトのWorkerへ送られ、Workerが公開サイトへ匿名でアクセスします。Cookieや認証情報は転送しません。
公開URLを入力し、手動で確認してください。
HTTPヘッダー確認は、更新後のキャッシュが古いままか、意図しない転送が起きているかを切り分ける手掛かりになります。入力したURLそのものの最初の応答を記録します。
HTTPレスポンスヘッダーの確認では、ブラウザーで最後に開いた画面とこの記録を混同しないでください。HEADを先に試し、拒否された場合だけGETに切り替えます。
HTTPヘッダー確認を使う理由
転送前の応答と実際の値を残す
最初の転送を見失わない
HTTPヘッダー確認は301や302のLocationをそのまま表示します。転送先まで自動で進まないため、最初の設定ミスを見落としません。
値を用途ごとに比べる
セキュリティヘッダーとキャッシュヘッダーを分け、その他のフィールドも保持します。見つからない項目は今回の匿名応答についての表示で、安全性の採点ではありません。
この観測を正しく読むために
02
メソッドと転送先を確認
最初はHEADです。405または501なら本文を破棄するGETを一度試します。3xxのLocationは表示しますが、転送先を自動取得しません。
03
現在の結果だけ保存
確認時刻は対象のDateヘッダーではなく、この要求が完了した時刻です。URL変更後は結果が古くなり、コピーと保存が無効になります。
応答から読み取れる情報
ステータスと実際の方式
404や500も有効な応答としてヘッダーを表示します。HEADからGETに切り替わった場合はレポートに明記します。
安全性の設定値
CSP、HSTS、Referrer-Policyなどの値を確認できます。HTTPヘッダーチェッカーとして存在だけで安全と断定することはしません。
キャッシュの手掛かり
Cache-Control、ETag、Varyの値を残し、配信網と元サーバーで異なる応答を調べる材料にします。
対象と判断の限界
- 公開ホストだけ
- localhost、内部・予約済みアドレス、認証情報付きURL、通常外のポートは拒否します。
- 一つ目の応答だけ
- 転送チェーンやPOST、Cookie、認証ヘッダーは扱いません。必要なら専用のHTTPクライアントを使ってください。
- 欠落は脆弱性の証拠ではない
- 必要なポリシーはサイトごとに違います。見つからないヘッダーを示しますが、安全スコアは付けません。
- ブラウザーとは視点が違う
- Workerの匿名要求なので、地域、CDN、ログイン状態、User-AgentによってブラウザーのNetwork表示と異なる場合があります。
HTTPヘッダー確認の質問
どんなHTTPヘッダーを表示しますか？
最初の応答に含まれる全フィールドを表示し、よく使う安全性とキャッシュの項目を分けます。ステータス、方式、確認時刻も記録します。
HTTPヘッダーはSEOやデバッグになぜ役立ちますか？
転送、キャッシュ、コンテンツの扱いを調べる材料になります。ただしヘッダーだけで検索評価や安全性は決まりません。
URLにhttps://が必要ですか？
ドメイン名だけでも入力できます。その場合はHTTPSを補います。HTTPを調べたいならhttp://を明示してください。
取得がエラーになるのはなぜですか？
対象が匿名のHEAD要求を拒否したり、名前解決に失敗したり、５秒以内に応答しない場合があります。405と501ではGETを試します。
無料で使えますか？URLは非公開ですか？
利用に課金はありませんが、URLは当サイトのWorkerと対象サイトへ送られます。認証情報は転送せず、結果はページの現在のセッション内に保持します。
疑問が残っていますか？