結論（セキュリティヘッダー）
セキュリティヘッダーの診断では、クリックジャッキング対策（frame-ancestors・X-Frame-Options）、MIMEスニッフィング対策（nosniff）、Referrer-Policy、Permissions-Policy、COOP・COEP・CORPなどのレスポンスヘッダーが正しい値で返っているかを確かめます。トップページだけでなく、下層ページ・エラー応答を含む全応答に一貫して付いているかも確認します。
セキュリティヘッダーの診断項目一覧（13項目）
クリックジャッキング、MIMEスニッフィング、情報漏えいを防ぐHTTPレスポンスヘッダーを確認します。各項目名から、意味・診断基準・リスク・具体的な対策を解説したページへ移動できます。
| No. | 診断項目 | 重大度 | 概要 |
|---|---|---|---|
| 16 | クリックジャッキング対策 | high | クリックジャッキング対策は、自サイトを他サイトのiframeに埋め込ませないようブラウザに指示するヘッダー設定です。 |
| 17 | MIMEスニッフィング対策 | medium | MIMEスニッフィング対策は、全応答にX-Content-Type-Options: nosniffを付けるだけで実施できます。 |
| 18 | Referrer-Policy | medium | Referrer-Policyは、外部へ送るRefererの範囲を決めるヘッダーです。 |
| 19 | Permissions-Policy | low | Permissions-Policyは、カメラ・マイク・位置情報などのブラウザ機能を使える範囲を宣言するヘッダーです。 |
| 20 | Cross-Origin-Opener-Policy | low | Cross-Origin-Opener-Policy（COOP）は、別オリジンのウィンドウとの参照関係を切り離すヘッダーです。 |
| 21 | Cross-Origin-Embedder-Policy | low | Cross-Origin-Embedder-Policy（COEP）は、クロスオリジン分離を実現するためのヘッダーです。 |
| 22 | Cross-Origin-Resource-Policy | low | Cross-Origin-Resource-Policy（CORP）は、自サイトのリソースを他サイトからno-corsで読み込ませる範囲を宣言するヘッダーです。 |
| 23 | レガシーなクロスドメイン許可を制限 | low | レガシーなクロスドメイン許可を制限する対策は、X-Permitted-Cross-Domain-Policies: noneを返すことです。 |
| 97 | ページ間のセキュリティヘッダー整合性 | medium | ページ間のセキュリティヘッダー整合性とは、CSP・nosniff・Referrer-Policy・X-Frame-Optionsが全ページで揃っている状態です。 |
| 117 | HSTSを全HTTPS応答へ適用 | high | HSTSを全HTTPS応答へ適用とは、トップページだけでなく下層ページ・API・エラー応答にもStrict-Transport-Securityを付けることです。 |
| 118 | クリックジャッキング対策を全HTMLへ適用 | high | クリックジャッキング対策を全HTMLへ適用とは、下層ページやエラーページを含む全HTML応答にX-Frame-OptionsかCSP frame-ancestorsを付けることで… |
| 119 | CSP frame-ancestorsを全HTMLへ適用 | high | CSP frame-ancestorsを全HTMLへ適用とは、全HTML応答のCSPヘッダーで埋め込み元を制限することです。 |
| 120 | nosniffを全応答へ適用 | medium | nosniffを全応答へ適用とは、HTMLだけでなくCSS・JavaScript・画像・404応答にもX-Content-Type-Options: nosniffを付けることで… |
セキュリティヘッダーの診断とは
セキュリティヘッダーの診断は、Webサーバーが返すHTTPレスポンスヘッダーのうち、ブラウザに安全な振る舞いを指示するものが、正しい値で、すべての応答に付いているかを確かめるものです。セキュリティ診断127項目のうち、クリックジャッキング、MIMEスニッフィング、情報漏えい、別オリジンとの関係の制御などにかかわる13項目がこの分類に入ります。
セキュリティヘッダーの多くは、ヘッダー1行で効果が出る一方、書式を誤ると黙って無視されるという性質があります。たとえばPermissions-Policyは書式を1か所でも誤るとヘッダー全体が無視され、X-Content-Type-Optionsは nosniff 以外の値では働きません。X-Frame-Optionsの ALLOW-FROM は現行ブラウザで無視されます。「ヘッダーを書いた」ことと「ヘッダーが効いている」ことは別なので、値まで確認することが大切です。
もう1つの観点が「全応答への適用」です。セキュリティヘッダーは応答ごとに評価されるため、トップページで正しく返っていても、下層ページや404ページ、別アプリの画面で欠けていれば、そのページは無防備です。攻撃者は最も守りの弱いページを狙います。この分類には、トップページの値を見る項目と、複数のページを巡回して付与漏れを見る項目の両方が含まれています。
13項目の全体像（4つのグループ）
この分類の13項目は、大きく4つのグループに分けて考えると整理しやすくなります。
| グループ | 診断項目 | 確認する内容 |
|---|---|---|
| 埋め込みの制御（クリックジャッキング） | 「クリックジャッキング対策」、「クリックジャッキング対策を全HTMLへ適用」、「CSP frame-ancestorsを全HTMLへ適用」 | frame-ancestors または X-Frame-Options（DENY／SAMEORIGIN）で他サイトからの埋め込みを禁止しているか、下層ページやエラーページにも付いているか |
| 型推測と情報漏えいの防止 | 「MIMEスニッフィング対策」、「nosniffを全応答へ適用」、「Referrer-Policy」 | X-Content-Type-Options: nosniff が全応答に付いているか、遷移元URLを外部へどこまで送るかを安全な値で指定しているか |
| ブラウザ機能と別オリジンとの関係 | 「Permissions-Policy」、「Cross-Origin-Opener-Policy」、「Cross-Origin-Embedder-Policy」、「Cross-Origin-Resource-Policy」、「レガシーなクロスドメイン許可を制限」 | カメラ・マイク等の強力な機能の制限、別オリジンのウィンドウとの分離、埋め込み読み込みの許可範囲、Acrobat/Reader等が参照するクロスドメインポリシーの無効化 |
| 全ページでの一貫性 | 「ページ間のセキュリティヘッダー整合性」、「HSTSを全HTTPS応答へ適用」 | CSP・nosniff・Referrer-Policy・X-Frame-Optionsがページ間で同じ値か、HSTSが下層ページやエラー応答を含む全HTTPS応答に付いているか |
巡回系の項目では、セキュリティAIチェッカーがトップページと同一オリジンの下層ページを取得して比べます。「ページ間のセキュリティヘッダー整合性」は差があれば△で×は出さず、CSPのnonceは応答ごとに変わるのが正しいため比較の前に正規化しています。
優先して確認すべき項目
この分類に重大度「最重要（critical）」の項目はありません。「重要（high）」の4項目から確認します。
- クリックジャッキング対策：攻撃者のサイトに自サイトを透明なiframeで重ね、別のボタンに見せかけて操作させる攻撃を防ぎます。現行の標準はCSPの frame-ancestors 'self'（または 'none'）で、X-Frame-Options: SAMEORIGIN（または DENY）を互換のために併用します。
- クリックジャッキング対策を全HTMLへ適用：攻撃者が狙うのは、申請送信・設定変更などのボタンがある下層ページです。1ページでも保護がなければ×になります。
- CSP frame-ancestorsを全HTMLへ適用：この項目はX-Frame-Optionsだけの応答を不合格とし、全HTML応答のCSPヘッダーに frame-ancestors があるかを確認します。metaタグのCSPやReport-Onlyでは埋め込みを阻止できません。
- HSTSを全HTTPS応答へ適用：利用者が最初に訪れるページはトップとは限らないため、下層ページ・API・404などのエラー応答を含むすべてのHTTPS応答に付けます。
次に「中（medium）」の項目として、MIMEスニッフィング対策と、その全応答への適用、Referrer-Policy、ページ間の整合性を整えます。nosniffはアップロードファイルがHTMLとして実行されるXSSや、型の違うファイルがスクリプト・CSSとして読み込まれる事故を防ぎ、Referrer-PolicyはURLに含まれる検索語やトークンが第三者へ漏れるのを防ぎます。
「低（low）」のPermissions-Policy、COOP、COEP、CORP、レガシーなクロスドメイン許可の制限は、多層防御として基本の設定がそろった後に検討します。
直すときの進め方と注意点
セキュリティヘッダーは、ページ単位ではなくWebサーバー全体やCDNの共通設定で一括付与し、エラー応答にも付くようにするのが基本です。進めるときは次の点に注意します。
- エラー応答にも付ける：Apacheで always を付けずに Header set と書くと、既定では成功応答にしか付与されません。Header always set にすると、エラー応答にも付きます。nginxでは add_header に always を付けます。
- nginxの継承の切れ目に注意する：nginxでは、location に add_header が1つでもあると上位の設定が継承されません。共通ヘッダーをincludeファイルにまとめて各 location でも読み込むか、nginx 1.29.3以降なら add_header_inherit merge を使います。
- 付与箇所を1か所にまとめる：WebサーバーとCMSの両方で付与すると、値の重複や食い違いが起きます。X-Frame-Options: DENY, SAMEORIGIN のように異なる有効値が混在すると埋め込みは全面的にブロックされます。
- frame-ancestorsとX-Frame-Optionsの関係を理解する：強制CSPに frame-ancestors があるとX-Frame-Optionsは無視されるため、frame-ancestors * と DENY の併記は埋め込みを許してしまいます。埋め込みが不要なサイトは frame-ancestors 'self' と X-Frame-Options: SAMEORIGIN の併記が基本です。
- nosniffの前にContent-Typeを確かめる：nosniffが有効だと、JavaScriptのMIMEタイプでないスクリプトや text/css でないスタイルシートはブロックされます。エラーが出たらnosniffを外さず、Content-Typeを直します。
- COEPは慎重に入れる：require-corp を全体に入れると、CORPを返さない外部の画像・地図・動画・SNS埋め込みが読み込めなくなります。分離が不要なサイトは設定せず△を許容し、必要なアプリのパスだけに Report-Only から導入するのが安全です。
自治体・公共機関のサイトで特に注意すること
自治体や公共機関のサイトは、CMSで作った公式サイトに、別に調達した申請システムや特設サイト、地図・カレンダーなどが組み合わさっていることが多く、ヘッダーの付与漏れや食い違いが起きやすい構成です。よくある状況として、次のようなものがあります。
- トップページではヘッダーが返っているが、CMSと別アプリが混在しているため、申請画面や404ページでは欠けている。
- 自サイト内で自分のページをiframe表示する構成（地図、カレンダー、多層iframeのポータル）があり、frame-ancestors 'none' にすると表示が壊れる。まず 'self' から始め、他のサイトから埋め込まれる必要がある場合は許可するオリジンを列挙します。
- 手続き画面や職員用システムのURLに識別子が含まれる。サイト全体は strict-origin-when-cross-origin とし、特に守りたい領域は no-referrer または same-origin を個別に設定します。
管理しているドメインや画面ごとに、どこでヘッダーを付与しているかを一覧にし、トップページだけでなく下層ページとエラー応答でも定期的に確認すると、こうした付与漏れを防ぎやすくなります。
よくある質問（FAQ）
セキュリティヘッダーの診断項目は、どの順番で直せばよいですか？
まず重要（high）のクリックジャッキング対策と、HSTS・クリックジャッキング対策・CSP frame-ancestorsの全応答への適用を整えます。次にnosniff、Referrer-Policy、ページ間の整合性（中）を確認し、Permissions-Policy、COOP・COEP・CORP、レガシーなクロスドメイン許可の制限（低）は最後に検討します。
トップページのセキュリティヘッダー診断で問題がなければ、サイト全体も安全ですか？
安全とは限りません。セキュリティヘッダーは応答ごとに評価されるため、下層ページや404ページ、別アプリの画面で欠けていれば、そのページは無防備です。Webサーバー全体やCDNで一括付与し、エラー応答にも付くようにします。
セキュリティヘッダーはmetaタグで設定できますか？
クリックジャッキング対策はできません。X-Frame-OptionsはHTTPヘッダーでのみ有効で、CSPのframe-ancestorsもmeta要素では無視されます。セキュリティヘッダーはレスポンスヘッダーで送るのが基本です。
404ページだけセキュリティヘッダーが出ないのはなぜですか？
Apacheで always を付けずに Header set と書いている場合が典型です。既定では成功応答にしか付与されないため、Header always set に変えるとエラー応答にも付きます。nginxでは add_header に always を付け、location に add_header を書くと上位の設定が継承されない点にも注意します。
COEPのようなセキュリティヘッダーは自治体サイトにも必須ですか？
必須ではありません。COEPはクロスオリジン分離を前提とする機能のための仕組みで、一般的な公式サイトでは通常不要です。不用意に require-corp を入れると外部の地図や動画が表示されなくなるため、診断の△を許容する運用も合理的です。
セキュリティヘッダーの13項目はまとめて確認できますか？
セキュリティAIチェッカーにURLを入力すると、この13項目を含む127項目を公開情報から自動で診断し、項目ごとの判定と改善の優先順位を表示します。