HTTPヘッダーチェッカー

HTTPヘッダー解析ツールです。どのURLのHTTPヘッダーも、サーバーが送ったとおりに順序も重複もそのまま確認できます。Mozilla HTTP Observatoryと同じテストでセキュリティ評価を付け、nginx、Apache、IIS、Cloudflare、Vercel、Netlify、Express向けの修正例も表示します。キャッシュ、Cookie、サーバー情報も確認できます。

更新日: 2026年10月24日

当サーバーから1回リクエストし、生のヘッダーを順序どおりに保持 · Mozilla HTTP Observatoryの公開テスト（アルゴリズム6） · Cookieの値は表示も保存もしません

リダイレクトを最終ページまでたどり、そのページを評価します。各ホップのヘッダーは「リダイレクト」にあります。

例

HTTPヘッダーとは？

HTTPヘッダーとは、ページ本体より先にサーバーが送る行のことです。ステータス行、続いて1行に1つのname: valueフィールド、空行、本文の順に並びます（RFC 9110）。名前は大文字小文字を区別せず、値はサーバー独自のものです。

レスポンスヘッダーは、コンテンツの種類、コピーを保持できる期間、保存するCookie、適用するセキュリティルールをブラウザーに伝えます。このチェッカーは、それらを送信されたまま、順序も重複もそのままに表示し、役割ごとに各行を色分けします。

レスポンスの構造github.com · 2026年10月24日記録

ステータス行HTTP/1.1200OK

フィールド行Strict-Transport-Security: max-age=31536000; includeSubdomains; preload

X-Frame-Options: deny

Cache-Control: max-age=0, private, must-revalidate

Content-Type: text/html; charset=utf-8

Set-Cookie: _gh_sess=‹344文字›; path=/; HttpOnly; secure; SameSite=Lax

Server: github.com

… 他14行

本文<!DOCTYPE html><html lang="en" …

セキュリティブラウザーが適用すべきこと

キャッシュコピーを再利用できる期間

Cookieブラウザーが保存するもの

サーバーとエッジ応答した主体と経由したCDN

WebサイトのHTTPヘッダーを確認するには？

上のフィールドにURLを入力してヘッダーを確認を選ぶと、チェッカーが当サーバーからURLにアクセスし、最終ページまでリダイレクトをたどって、そのページのレスポンスヘッダーを1行ずつ表示し、横にセキュリティ評価を示します。ヘッダーだけを取得するには、メソッドのボックスでHEADを選びます。

任意の行を選ぶと、その役割と値の意味が表示されます。下のビューでは、結果を種類別に整理します：修正方法をサーバー別に示すセキュリティ、キャッシュ、Cookie、サーバーとプロトコル、リダイレクトです。

ヘッダーチェッカー：送信されたままのレスポンス

元の大文字小文字と順序、重複を保持し、HTTP/1.1で取得します。長い値は折り返し、Cookieの値は表示しません。Cloudflareの背後にあるサイトはCloudflareのネットワーク経由で取得し、結果にもその旨を表示します。

Mozilla Observatoryのテストでセキュリティヘッダーを確認

Observatoryのコードと同じ12のテストと配点で、両ラウンドをスコア列で計算し、Mozilla公式のホストスキャンへのリンクも表示します。

サーバーヘッダーチェッカー：ソフトウェア、CDN、プロトコル

ServerとX-Powered-By（漏えいしているバージョンを含む）、CDNとそのキャッシュステータス、TLSバージョン、HTTP/2、HTTP/3を表示します。

HSTSチェッカーとプリロードの準備状況

max-age、includeSubDomains、preloadをhstspreload.orgの要件に照らして参考情報として表示します。プリロードは任意です。

github.com のHTTPヘッダー確認：送信されたままのレスポンスヘッダーと、115点のA+セキュリティ評価 — github.com のヘッダー確認：評価と判定、送信されたままのレスポンス、Mozilla HTTP Observatoryの2つのラウンドの計算。番号を選ぶと各部分の内容が表示されます。

すべてのサイトが送るべきセキュリティヘッダーは？

まず4つから始めましょう：Content-Security-Policy、Strict-Transport-Security、フレーミング対策（X-Frame-OptionsまたはCSPのframe-ancestors）、X-Content-Type-Options: nosniffです。これらが欠けると、Mozilla HTTP Observatoryの評価で最も多くの点を失います。

Referrer-Policyとクロスオリジンポリシー（COOP、COEP、CORP）は、基本が整えばボーナス点になります。Permissions-Policyは設定する価値がありますが、読み取るのはChromiumベースのブラウザーだけで、Observatoryでは採点されません。

セキュリティヘッダーと、それぞれの配点Mozilla HTTP Observatory · アルゴリズム6

ヘッダー	防ぐもの	欠けた場合	適切に設定	対応ブラウザー
Content-Security-Policy	注入されたスクリプト	−25	+5 / +10
Strict-Transport-Security	http://へのダウングレード	−20	+5 プリロード済み
X-Frame-Options · frame-ancestors	隠しフレームによるクリックジャッキング	−20	+5
X-Content-Type-Options	誤った種類として実行されるファイル	−5	0
Referrer-Policy	完全なURLの他サイトへの漏えい	0	+5
Cross-Origin-Opener-Policy	他のウィンドウからの干渉	0	+10
Cross-Origin-Embedder-Policy	オプトインしていないものの読み込み	0	+10
Cross-Origin-Resource-Policy	他サイトによるファイルの埋め込み	0	+10
Permissions-Policy	埋め込みによるカメラ、マイク、位置情報の利用	—	採点なし	のみ

ボーナスは、減点後もスコアが90以上の場合にだけ加算されます。Observatoryのその他のテストでは、Cookie、サブリソース完全性、CORS、HTTPSへのリダイレクトを調べます。

セキュリティ評価はどのように計算されますか？

Mozilla HTTP Observatoryの方法をテストごとにそのまま採用しています。100点から始めて、すべての減点を差し引き、結果が90点以上の場合にだけボーナスを加算します。その後、スコアはFからA+までの評価に変換されます（Observatoryの採点ドキュメント）。

この2回目のラウンドは意外に思われがちです。大きな失点が1つあるサイトは、ボーナスを一切受け取れません。2026年にCOOPとCOEPが追加されたため、Observatoryのコードでは最大165点まで取れますが、ドキュメントでは2026年10月24日時点でまだ145点とされていました。当サイトはコードに従っています。すべての結果にMozilla公式のホストスキャンへのリンクがあるので、比較できます。

2つのサイトの計算例Observatory自身の結果、2026年10月24日

github.comA+

開始100
外部スクリプトにSRIなし−595
90以上：ボーナスラウンドを加算
Cookie：Secure、HttpOnly、SameSite+5
Referrer-Policy+5
HSTSプリロード済み+5
CSPによるフレーミング対策+5
スコア115

www.mozilla.orgB+

開始100
CSPが'unsafe-inline'を許可−2080
90未満：ボーナスラウンドはスキップ
COOP same-origin+10
Referrer-Policy+5
CSPによるフレーミング対策+5
スコア80

FD-DD+C-CC+B-BB+A-AA+

11580120修正後

Mozillaのサイトは、CSPのディレクティブ1つで20点を失い、すでに獲得していた20点のボーナスも加算されません。そのscript-srcから'unsafe-inline'と'unsafe-eval'を外せば、同じヘッダーで120になります。

HSTSとは？プリロードすべきですか？

Strict-Transport-Securityは、max-age秒の間、そのホストにはhttps://だけを使うようブラウザーに伝え、includeSubDomainsを付けるとすべてのサブドメインにも適用されます（RFC 6797）。通常のhttp://経由ではブラウザーに無視され、最初のヘッダーだけが有効です。Observatoryは、未設定の場合に20点、max-ageが6か月未満の場合に10点を減点します。

プリロードは任意です。hstspreload.orgは現在、HSTSは推奨するがプリロードは推奨しないとしています。ChromeとSafariはすでにナビゲーションをHTTPSにアップグレードしており、リストから外れるには数か月かかるためです。それでも申請するなら、1年以上のmax-age、includeSubDomains、preload、すべてのサブドメインでのHTTPSが必要です。先にmax-ageを段階的に引き上げてください。

2つのドメインとhstspreload.orgの要件2026年10月24日記録 · 参考情報

github.comプリロードリストに登録済み

有効な証明書
同じホストで先にhttp://からhttps://へhttp://github.com → https://github.com/
wwwもHTTPSに対応
31536000以上のmax-agemax-age=31536000
includeSubDomains
preload
https://へのリダイレクトにもHSTS

mozilla.orgリスト未登録

有効な証明書
同じホストで先にhttp://からhttps://へ302 → https://mozilla.org:443/
wwwもHTTPSに対応
31536000以上のmax-agemax-age=60
includeSubDomains
preload · 未送信
https://へのリダイレクトにもHSTS

hstspreload.orgが勧めるmax-ageの段階的な引き上げ

3005 分 · テスト用
6048007 日
259200030 日
31536000365 日 · プリロードの最小値

どちらの結果も欠点ではありません。hstspreload.orgは、ほとんどのサイトにプリロードは推奨しないとしており、プリロードがなくても、HSTSは2回目以降の訪問者全員を保護します。

Content-Security-Policyは何をするものですか？

Content-Security-Policyは、ページがスクリプト、スタイル、画像、フレームを読み込める場所を列挙するもので、攻撃者が他の場所から注入したスクリプトは実行されません。frame-ancestorsディレクティブはページをフレームに入れられる相手も指定し、X-Frame-Optionsより優先されます（CSP Level 3）。

script-srcの'unsafe-inline'は保護の大半を無効にするため、Observatoryは20点を減点します。代わりにnonceまたはハッシュを使ってください（リストにどちらかがあると、ブラウザーは'unsafe-inline'を無視します）。Content-Security-Policy-Report-Onlyヘッダーは何もブロックせず、報告するだけなので、新しいポリシーを先に試す安全な方法です。

ディレクティブごとのCSPgithub.comとwww.mozilla.org · 2026年10月24日

github.com

default-src以下に挙げていないすべて'none'

base-uriページの<base href>'self'

script-srcスクリプトの読み込み元github.githubassets.com 'sha256-6AKuI+cDd1MoUL1u4eqrA9PXmnPAkOB4h7421hPUUm0='

style-srcスタイルシート'unsafe-inline' github.githubassets.com

img-src画像'self' data: blob: github.githubassets.com media.githubusercontent.com camo.githubusercontent.com …

frame-ancestorsこのページをフレームに入れられる相手'none'

form-actionフォームの送信先'self' github.com gist.github.com copilot-workspace.githubnext.com …

script-src www.mozilla.orgの場合'self' 'unsafe-eval' 'unsafe-inline' *.google-analytics.com *.googletagmanager.com google-analytics.com …

github.comはdefault-src 'none'から始めて、各ソースを名前で許可しています。リストにnonceまたはハッシュがあるとブラウザーは'unsafe-inline'を無視し、Observatoryもそれを数えません。

Cache-Controlの解説：コピーはどのくらい再利用できる？

max-ageで示された秒数の間です。Cache-Controlは、サーバーに再確認せずにレスポンスを再利用できる期間をブラウザーとCDNに伝え、s-maxageはCDNなどの共有キャッシュ用に別の期間を設定します（RFC 9111）。

no-cacheは「キャッシュしない」という意味ではありません。保存はするが、再利用の前に毎回サーバーに確認するという意味です。no-storeはあらゆるキャッシュに残しません。Ageヘッダーは、CDNのコピーがすでにどれだけ古いかを示します。Cache-Controlがまったくない場合、ブラウザーはLast-Modifiedからの経過時間の約10%を有効期間として推測することがあります。

コピーが新鮮でいられる期間www.wikipedia.org · 2026年10月24日記録

Cache-Control: s-maxage=86400, must-revalidate, max-age=3600

共有キャッシュ（CDN）s-maxage=86400 · 24 時間残り21 時間 39 分

ブラウザーmax-age=3600 · 1 時間期限切れ

no-store	どのキャッシュにも書き込まない
no-cache	保存はするが、再利用の前に毎回サーバーへ確認
max-age=N	N秒間は新鮮（Expiresは無視される）
s-maxage=N	同じ内容を共有キャッシュにのみ適用
private	ブラウザーのみ、CDNには保存しない
immutable	再読み込みで再検証しない（Chromeは無視）

CDNのコピーは、当サーバーに届いた時点ですでに2 時間 20 分経過しており、ブラウザーの1 時間を過ぎています。このコピーを受け取ったブラウザーは、再利用の前にサーバーへ確認（ETagリクエスト）する必要があります。

SecureはCookieをHTTPSでのみ送信し、HttpOnlyはスクリプトからCookieを隠し、SameSiteは他サイトからのリクエストにCookieを付けるかどうかを決めます。Strictは付けず、Laxはトップレベルのリンクのみ、Noneは常に付けますが、その場合はSecureが必須です。

セッションCookieとログインCookieには、3つすべてが必要です。SameSiteのないCookieをLaxとして扱うのはChromeとEdgeだけで、FirefoxとSafariはクロスサイトのリクエストでも送信するため、自分で設定してください。このチェッカーは、各Cookieの名前、長さ、フラグを一覧にします。値は表示も保存もしません。

Cookieごとのフラグwww.youtube.com · 7個のCookie · 値は非表示

Cookie	SameSite	Partitioned	有効期間
__Secure-YNID	None		180日
GPS	—	—	30分
YSC	None		ブラウザーを閉じるまで
__Secure-YEC	Lax	—	削除
VISITOR_INFO1_LIVE	None		180日
VISITOR_PRIVACY_METADATA	None		180日
__Secure-ROLLOUT_TOKEN	None		180日

SameSite=NoneにはSecureが必要ないとブラウザーに拒否されます。PartitionedにもSecureが必要です。

__Host-プレフィックスSecure、Path=/、Domainなしが必須で、満たさないとCookieは拒否されます。

最大400日Chromeはそれより長いExpiresやMax-Ageを短縮します（バージョン104以降）。

過去のExpires日付は、サーバーがCookieを削除する方法です。__Secure-YECは保持されず、削除されます。

非推奨のHTTPヘッダーは？

X-XSS-Protection、Expect-CT、Public-Key-Pins、Feature-Policy、P3Pは、現在のブラウザーでは役に立つ働きをしません。X-XSS-Protectionは0にするか、送らないようにしてください。古いフィルター自体が脆弱性の原因になり得るためです（OWASP）。

Serverのバージョン番号やX-Powered-Byヘッダーは非推奨ではありませんが、RFC 9110とOWASPはどちらも出さないよう勧めています。攻撃者に、どの既知のバグを試せばよいかを教えてしまうからです（RFC 9110 §10.2.4）。

削除してよいヘッダーOWASP · Chromium · RFC 9110

X-XSS-Protection: 1; mode=block

0を送るか、送らない

Chrome 78とSafari 15.4はXSSフィルターを削除しました。Firefoxには最初からありません。github.comとwww.google.comは0を送っています。

Chrome

Expect-CT

削除する

Chrome 107以降は非推奨：Certificate Transparencyはどのみち強制されます。

Chrome

Public-Key-Pins

削除する

Chrome 72で削除されました。現在対応しているブラウザーはありません。

Chrome

Feature-Policy

Permissions-Policyを使う

名前が変更されました：古いヘッダーは非推奨です。

Chrome

P3P

削除する

現在のブラウザーが読まない、廃れたプライバシー規格です。www.youtube.comは今も送っています。

YouTube

Server: Apache/2.4.62 (Ubuntu)
X-Powered-By: PHP/8.3.12

バージョンを外す

架空の例：RFC 9110とOWASPは、この詳細は攻撃者を助けるだけだとしています。

Apache

ChromeやcurlでHTTPヘッダーを確認するには？

Chromeでは、DevTools（F12）を開いてネットワークを選び、再読み込みして最初の行をクリックし、ヘッダーを開きます。curlでは、curl -sI https://example.comでレスポンスヘッダーを出力できます。--http1.1を付けると、サーバー自身の表記で表示されます。

HTTP/2とHTTP/3では、規則によりすべてのヘッダー名が小文字になります（RFC 9113 §8.2.1）。そのため、サーバーがStrict-Transport-Securityと書いていても、DevToolsにはstrict-transport-securityと表示されます。このチェッカーはHTTP/1.1で取得し、ヘッダーを送信されたままに保持します。

自分でヘッダーを確認するcurl · Chrome DevTools

$ curl -sI --http1.1 https://github.com
HTTP/1.1 200 OK
Date: Sat, 24 Oct 2026 08:19:43 GMT
Content-Type: text/html; charset=utf-8
Vary: X-PJAX, X-PJAX-Container, Turbo-Visit, Turbo-Frame, X-Reques…
content-language: en-US
ETag: W/"6995be88733b84f6fb0c35e84ad1df53"
Cache-Control: max-age=0, private, must-revalidate
Strict-Transport-Security: max-age=31536000; includeSubdomains; preload
X-Frame-Options: deny
X-Content-Type-Options: nosniff
…

ヘッダープレビューレスポンスタイミング

DevTools › ネットワーク › ドキュメントの行 › ヘッダー。 Rawにチェックを入れると、受信したままの行を確認できます。HTTP/2ではすべての名前が小文字で届きます。--http1.1を使うと、サーバー自身の表記で表示されます。

HTTPヘッダーチェッカー：よくある質問

良いセキュリティヘッダーの評価とは？

Mozilla HTTP Observatoryの基準でAまたはA+です。90点以上で、ボーナスラウンドが加算されます。セキュリティヘッダーがまったくないサイトは、たいていDかFあたりになります。安全でないソースのないCSP、HSTS、フレーミング対策、nosniffを追加すると100点に達し、さらにReferrer-Policy、Cookie、クロスオリジンポリシーで100点を超えてA+になります。

評価がsecurityheaders.comと異なるのはなぜですか？

測っているものが違うためです。securityheaders.comは主にどのヘッダーがあるかで採点し、その配点方式は運営者が最後に説明したのが2023年です。当サイトはMozilla HTTP Observatoryの公開テストに従い、値、Cookie、HTTPSへのリダイレクトも読み取り、90点以上の場合にだけボーナスを加算します。各結果にMozilla公式のホストスキャンへのリンクがあるので、比較できます。

セキュリティヘッダーでサイトが壊れることはありますか？

はい、2つは壊す可能性があります。厳格なContent-Security-Policyは、サイトに必要なスクリプトやスタイルをブロックすることがあり、includeSubDomains付きのHSTSは、HTTPSのないサブドメインを使えなくします。新しいCSPは、まずContent-Security-Policy-Report-Onlyで導入してレポートを確認してから適用してください。HSTSのmax-ageは、5分から始めて段階的に引き上げ、その後で1年にします。

HEADリクエストでHTTPヘッダーを確認できますか？

はい。URLの横のメソッドのボックスでHEADを選びます。サーバーは、GETの場合と同じヘッダーを本文なしで返すはずですが、HEADへの応答が異なるサーバーやCDNもあります。また、サブリソース完全性のようにHTMLを読むテストは、読むページがありません。GETが既定なのは、ブラウザーが受け取るものをそのまま確認できるためです。

X-XSS-Protectionはまだ必要ですか？

いいえ。このヘッダーが制御していたXSSフィルターは、現在のどのブラウザーにもありません。Chromeはバージョン78で、Safariは15.4で削除し、Firefoxには最初からありませんでした。OWASPは、古いフィルター自体が悪用され得るため、X-XSS-Protection: 0を送るか、何も送らないよう勧めており、Mozilla Observatoryも2024年にこのテストを廃止しました。現在、注入されたスクリプトを防ぐのはContent-Security-Policyです。

X-Content-Type-Options: nosniffは何をしますか？

ブラウザーに、内容から推測せず、サーバーが送るContent-Typeを信頼するよう伝えます。nosniffがあると、誤った種類で配信されたスクリプトやスタイルシートはブロックされるため、アップロードされたファイルがJavaScriptとして実行されることはありません。有効な値はこれだけで、ヘッダーがない場合や無効な場合、Observatoryは5点を減点します。

Chrome DevToolsでヘッダー名が小文字なのはなぜですか？

ページがHTTP/2またはHTTP/3で届いたためで、これらのプロトコルではすべてのヘッダー名が小文字でなければなりません（RFC 9113 §8.2.1）。ヘッダー名は大文字小文字を区別しないので、問題はありません。HTTP/1.1ではサーバー自身の表記で届き、このチェッカーはそれを読み取るため、同じレスポンスでも、ここではStrict-Transport-Security、DevToolsではstrict-transport-securityと表示されることがあります。

nginxやCloudflareでセキュリティヘッダーを追加するには？

nginxでは、serverブロックにヘッダーごとのadd_header行を追加し、エラーページにも付くようalwaysを指定して、リロードします。Cloudflareでは、レスポンスヘッダー変換ルールを使うか、Pagesなら_headersファイルを使います。その後ここで確認してください。セキュリティビューの不合格のテストごとに、nginx、Apache、IIS、Cloudflare、Vercel、Netlify、Express向けのスニペットがすぐ使える形で表示されます。

Serverヘッダーとは何ですか？隠すべきですか？

応答したソフトウェア（nginxやcloudflareなど）の名前です。製品名だけなら無害ですが、RFC 9110は細かい情報を出さないよう警告し、OWASPは簡略化を勧めています。Apache/2.4.62のようなバージョン番号は、攻撃者にどの既知のバグを試せばよいかを教えてしまうためです。X-Powered-Byは完全に削除してください。チェッカーのサーバーヘッダーのビューで、両方から何が漏れているかがわかります。

ヘッダーチェッカーはヘッダーやCookieを保存しますか？

いいえ。当サーバーからURLを取得して結果を表示し、再読み込みや共有リンクを素早く返すために2分間だけ保持し、その後は消去します。Cookieの値は表示も保存もしません。チェッカーが表示するのは、各Cookieの名前、値の長さ、フラグだけです。何もあなたと結び付けられることはなく、確認したサイトにあなたのアドレスが知られることもありません。

HTTPヘッダーチェッカー

HTTPヘッダーとは？