セキュリティヘッダーとは

セキュリティヘッダー (Security Headers) は、Web サーバーが HTTP レスポンスに付与するヘッダーで、ブラウザに対してセキュリティ上の動作を指示するものです。適切に設定することで、XSS、クリックジャッキング、MIME スニッフィングなどの攻撃を防御できます。

セキュリティヘッダーはサーバー側の設定だけで導入でき、アプリケーションコードの変更が不要な場合が多いため、コストパフォーマンスの高いセキュリティ対策です。HTTPS と組み合わせることで、Web サイトの防御力を大幅に向上させます。

主要なセキュリティヘッダー

Content-Security-Policy (CSP): ページ内で読み込めるリソース (スクリプト、スタイル、画像、フォントなど) のソースを制限する。インラインスクリプトの実行を禁止することで XSS 攻撃を大幅に軽減できる。最も強力だが、設定が複雑で既存サイトへの導入には慎重なテストが必要。
Strict-Transport-Security (HSTS): ブラウザに対して、以降のアクセスを常に HTTPS で行うよう指示する。HTTP から HTTPS へのリダイレクト時に発生する中間者攻撃のリスクを排除。max-age=31536000; includeSubDomains が推奨設定。
X-Content-Type-Options: nosniff を設定すると、ブラウザが Content-Type を無視してファイルの種類を推測する (MIME スニッフィング) のを防止する。設定は 1 行で済み、副作用もほぼないため、全サイトで設定すべき。
X-Frame-Options: ページが <iframe> 内に埋め込まれることを制限し、クリックジャッキング攻撃を防ぐ。DENY (完全拒否) または SAMEORIGIN (同一オリジンのみ許可) を設定。CSP の frame-ancestors ディレクティブで代替可能。
Referrer-Policy: 他サイトへのリンクをクリックした際に送信されるリファラー情報を制御する。strict-origin-when-cross-origin が推奨。URL にセッション ID やトークンが含まれる場合、リファラー経由で漏洩するリスクを軽減。
Permissions-Policy: カメラ、マイク、位置情報、加速度センサーなどのブラウザ API へのアクセスを制御する。使用しない機能を明示的に無効化することで、攻撃面を縮小。

セキュリティヘッダーの設定方法

セキュリティヘッダーは Web サーバーやリバースプロキシの設定で付与します。

Nginx の設定例

add_header X-Content-Type-Options "nosniff" always;
add_header X-Frame-Options "DENY" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;

CloudFront の設定

AWS CloudFront ではレスポンスヘッダーポリシーを使用してセキュリティヘッダーを一括設定できます。マネージドポリシー「SecurityHeadersPolicy」を適用するだけで、主要なセキュリティヘッダーが自動的に付与されます。

設定の検証

設定後は以下の方法で検証してください。

securityheaders.com: URL を入力するだけでセキュリティヘッダーの設定状況を A+ から F でスコアリングしてくれる無料ツール。
ブラウザの開発者ツール: Network タブでレスポンスヘッダーを直接確認。
curl コマンド: curl -I https://example.com でレスポンスヘッダーを取得。

導入時の注意点と優先順位

すべてのヘッダーを一度に導入する必要はありません。以下の優先順位で段階的に導入することを推奨します。

即座に導入 (副作用が少ない): X-Content-Type-Options、X-Frame-Options、Referrer-Policy
早期に導入 (HTTPS 前提): HSTS (まず短い max-age で試し、問題なければ延長)
慎重に導入 (テストが必要): CSP (まず Report-Only モードで影響を確認してから適用)

CSP は最も効果が高い反面、設定ミスでサイトの機能が壊れるリスクがあります。Content-Security-Policy-Report-Only ヘッダーを使えば、実際にはブロックせずに違反レポートだけを収集できるため、本番適用前のテストに活用してください。

CORS ヘッダーはセキュリティヘッダーと混同されがちですが、CORS はクロスオリジンリソース共有の制御であり、攻撃防御とは目的が異なります。

よくある誤解

HTTPS にすればセキュリティヘッダーは不要: HTTPS は通信経路の暗号化を提供しますが、XSS やクリックジャッキングなどのアプリケーション層の攻撃は防げません。セキュリティヘッダーは HTTPS とは異なるレイヤーの防御であり、併用が必要です。
セキュリティヘッダーを設定すると表示が崩れる: X-Content-Type-Options や X-Frame-Options は副作用がほとんどありません。表示に影響する可能性があるのは主に CSP ですが、Report-Only モードで事前テストすれば安全に導入できます。

セキュリティヘッダー