最も多い10のセキュリティヘッダーの誤り（と直し方）
セキュリティヘッダーは最も安価な堅牢化であり、同時に細部を誤りやすいものです。スキャナが最も多く指摘する10の誤りと、それぞれの具体的な直し方を紹介します。
HTTP 応答ヘッダーは、数行の設定ですべての訪問者を即座に守れる珍しいセキュリティ対策です。だからこそ誤りが多い——コピペが容易で、テストが難しいのです。スキャン結果に何度も現れる10の問題を挙げます。
1. HSTS がない（または preload のない HSTS）
Strict-Transport-Security がないと、HTTPS リダイレクト前の 1 回の平文リクエストが傍受されかねません。長い max-age を設定し、サブドメインを含めます。
Strict-Transport-Security: max-age=63072000; includeSubDomains; preloadすべてのサブドメインが HTTPS 専用になってから preload を追加してください——すぐには取り消しにくいためです。
2. unsafe-inline を許す Content-Security-Policy
script-src 'unsafe-inline' は、CSP が塞ぐはずの XSS の穴を再び開けます。nonce かハッシュに移行しましょう。
Content-Security-Policy: default-src 'self'; script-src 'self' 'nonce-{random}'; object-src 'none'; base-uri 'self'3. いつまでも report-only モードで出す
Content-Security-Policy-Report-Only は展開フェーズ用です。多くのサイトが何か月もそのままにし、レポートは集めるのに何も強制しません。report-only で違反を見つけ、落ち着いたら強制するヘッダーに切り替えましょう。
4. frame-ancestors ではなく X-Frame-Options
X-Frame-Options は旧式で、許可リストを表現できません。モダンブラウザが尊重する CSP ディレクティブを使いましょう。
Content-Security-Policy: frame-ancestors 'self'5. X-Content-Type-Options がない
X-Content-Type-Options: nosniff がないと、ブラウザが応答を MIME スニッフィングし、テキストとして返したものを実行しかねません。欠点のない 1 行のヘッダーです——必ず設定しましょう。
6. 危険な、またはない Referrer-Policy
既定では完全な URL（クエリ文字列中のトークンを含む）を第三者に漏らします。安全で広く互換性のある選択はこちら。
Referrer-Policy: strict-origin-when-cross-origin7. Permissions-Policy をブラウザ既定のままにする
アプリがカメラ・マイク・位置情報を使わないなら、明示しておきましょう。そうすれば侵害されたスクリプトも使えません。
Permissions-Policy: camera=(), microphone=(), geolocation=()8. HTML にはヘッダーを設定するが API には設定しない
フロントエンドのフレームワークが付けるヘッダーは、API ルート・リダイレクト・エラーページを取りこぼしがちです。スキャナはそれらのパスを直接テストします。セキュリティヘッダーはエッジ——リバースプロキシ、CDN、プラットフォームのミドルウェア——で設定し、網羅を均一にしましょう。
9. 複数の層からの矛盾するヘッダー
アプリと CDN の両方が Content-Security-Policy を設定すると、ブラウザは 2 つのヘッダーを見てその*共通部分*を適用し、機能を静かに壊すことがあります。権威ある 1 つの層を決め、重複を取り除きましょう。
10. 機微な応答をキャッシュする
認証済みページや個人データを含む API 応答は、共有プロキシにキャッシュされてはいけません。
Cache-Control: no-store再スキャンで確認する
ヘッダーは相互作用するので、小さなバッチで変更し、そのたびに再スキャンします。結果の読み方に不慣れなら、まずウェブサイトのセキュリティ診断レポートの読み方から。これらのヘッダーの下にある転送層についてはサイトを危険にさらす SSL/TLS の設定ミスを参照。完全なヘッダーチェックは毎回のスキャンで実行されます——機能ページの全チェックをご覧ください。