セキュリティヘッダの確認方法とチェックポイント（CSP・X-Frame-Options・HSTS）
セキュリティヘッダは、XSSやクリックジャッキングなどの攻撃からブラウザ側で利用者を守る設定です。HTTPレスポンスヘッダとして公開されているため、ブラウザの開発者ツールだけでも確認できます。
確認すべき項目
- CSP（Content-Security-Policy）の有無と安全性
- X-Frame-Options / frame-ancestors（クリックジャッキング対策）
- X-Content-Type-Options（nosniff）
- HSTS（常時HTTPS）・Referrer-Policy などの付与状況
なぜ重要か
ヘッダが未設定だと、混入した不正スクリプトの実行や、透明な枠を重ねて操作させるクリックジャッキングなどを防ぐ最後の砦が欠けた状態になります。多くは設定追加のみで対策でき、費用対効果が高い項目です。
自分で確認する手順
- レスポンスヘッダを見る：ブラウザの開発者ツール（Network タブ）で対象ページを開き、Response Headers を確認する。
curl -I https://example.jpでも同じ内容が得られる。 - CSPを判断する：
Content-Security-Policyがあるか、script-srcに'unsafe-inline'や*が含まれていないかを見る。Content-Security-Policy-Report-Onlyは記録のみで**強制されていない**点に注意。 - クリックジャッキング対策を判断する：
X-Frame-Options: DENY/SAMEORIGIN、または CSP のframe-ancestorsのどちらかがあれば対策済み。 - HSTSを判断する：
Strict-Transport-Securityのmax-ageが十分か（短すぎないか）、includeSubDomainsを付けてよい構成かを確認する。 - トップページだけでなく、ログイン画面・フォーム送信先など**重要なページでも同じヘッダが返るか**を確認する（配信経路が異なると付与漏れが起きやすい）。
よくある質問
どのヘッダから対応すべきですか？
影響と手間のバランスから、まず X-Frame-Options（またはCSPのframe-ancestors）、X-Content-Type-Options、HSTS の整備をおすすめします。CSPは既存のスクリプトを壊しやすいため、Report-Only で影響を測ってから強制に切り替えます。
ヘッダを付けるだけで安全になりますか？
いいえ。セキュリティヘッダはブラウザ側の防御を有効にする設定で、アプリ本体の脆弱性そのものを治すものではありません。攻撃が成立したときの被害を小さくする多層防御の一枚と考えてください。
ひとつずつ確認し続けるのが難しいときは
ここで挙げた検査は、サイトドックの月次の定期診断に含まれます。見つかった弱点のうちエッジで治せるものはその場で自動修復し、実施した対策は毎月のレポート（PDF）でお届けします。