セキュリティヘッダー入門｜CSP・HSTS・X-Frame-Optionsの設定と効果を実践解説

「脆弱性診断で『セキュリティヘッダーが不足している』と指摘されたが、どれを付ければ何が防げるのかわからない」「CSPを入れたら画面が真っ白になって慌てて外した」「HSTSは付けるだけと聞いたが、preloadの欄が怖くて触れない」。セキュリティヘッダーは設定自体は数行ですが、効果と副作用を理解せずに入れると、守るどころかサービスを止めてしまいます。

この記事では、主要なセキュリティヘッダーがそれぞれどの攻撃を防ぐのかを仕組みから説明し、影響の大きいCSPをReport-Onlyから段階的に導入する手順、nonceとhashの使い分け、HSTSのpreloadが「解除できない」リスク、Nginx・Next.js・Astroでの設定例、securityheaders.comでの確認方法までを解説します。XSSやCSRFの脆弱性そのものへの対策はXSS・CSRF対策入門、CORSはCORSの仕組みと設定で扱っているため、ここではヘッダーによる多層防御に絞ります。

セキュリティヘッダーとは何を防ぐものか

「ブラウザへの指示」で被害を限定する

セキュリティヘッダーは、サーバーがレスポンスに付けてブラウザに「このページをどう扱うべきか」を指示するものです。サーバー側の脆弱性を直すものではなく、脆弱性が突かれたときの被害を限定する、あるいは通信経路や埋め込みに関する攻撃をブラウザ側で拒否させる役割を持ちます。アプリのコードを直すのが一次対策、ヘッダーはそれを補う二次防御という位置づけです。

ヘッダー	防ぐ攻撃・問題	推奨値の例
Content-Security-Policy	XSSの影響軽減（不正スクリプトの実行阻止）、データ持ち出し先の制限	後述（サイトごとに設計）
Strict-Transport-Security	HTTPへのダウングレード・中間者攻撃	max-age=31536000; includeSubDomains
X-Frame-Options / CSPのframe-ancestors	クリックジャッキング（iframe内に埋め込んで誤クリックさせる）	DENY または SAMEORIGIN
X-Content-Type-Options	MIMEスニッフィング（画像として置いたファイルをスクリプト実行）	nosniff
Referrer-Policy	URLに含まれるIDやトークンの外部サイトへの漏えい	strict-origin-when-cross-origin
Permissions-Policy	カメラ・位置情報など不要なブラウザ機能の無効化	camera=(), microphone=(), geolocation=()

それぞれの仕組み

クリックジャッキングは、攻撃者のページに透明なiframeであなたのサイトを重ね、ユーザーが「送信」ボタンを押したつもりで別の操作をさせる手口です。X-Frame-Optionsは自サイトのページをiframeに入れてよいかをブラウザに指示し、DENYなら一切の埋め込みを拒否します。CSPのframe-ancestorsは同じ目的の後継で、埋め込みを許可するオリジンを個別に指定できます。

MIMEスニッフィングは、Content-Typeが曖昧なときにブラウザが中身を推測して解釈する挙動です。ユーザーがアップロードした「画像」に実はHTMLやスクリプトが含まれていた場合、推測によって実行されてしまうことがあります。nosniffは推測を禁止し、宣言されたContent-Typeどおりにしか扱わせません。

HSTSは「このドメインには今後HTTPSでしか接続するな」とブラウザに記憶させます。ユーザーがhttp://で打っても、ブラウザが通信前にhttpsへ書き換えるため、初回以降は平文の通信が一切発生せず、公衆Wi-Fiなどでのダウングレード攻撃を防ぎます。

CSPを段階的に導入する

CSPが「真っ白」を起こす理由

Content-Security-Policy（CSP）は、ページが読み込んでよいスクリプト・スタイル・画像・接続先などのオリジンをホワイトリストで指定するヘッダーです。XSSが起きても、許可されていない場所からのスクリプトやインラインスクリプトはブラウザが実行を拒否するため、被害を大幅に減らせます。その反面、自サイトが使っているGoogle AnalyticsやタグマネージャーやCDN上のフォント、inlineで書かれたイベントハンドラまですべて把握していないと、正規の機能まで止まります。これが「入れたら画面が壊れた」の正体です。

Report-Onlyで違反を集めてから強制する

1. Content-Security-Policy-Report-Onlyヘッダーで、ブロックはせず違反レポートだけを送らせる。
2. レポートの送信先（report-toまたはreport-uri）を用意し、数日〜数週間分の違反を集める。自前のエンドポイントでもよいし、レポート収集SaaSを使ってもよい。
3. 違反のうち正規のものをポリシーに追加し、インラインスクリプトはnonceかhashに置き換える。
4. 違反がほぼ出なくなったら、ヘッダー名をContent-Security-Policyに変えて強制モードにする。

# 段階1：Report-Onlyで様子を見る（Nginx）
add_header Content-Security-Policy-Report-Only
  "default-src 'self'; script-src 'self' https://www.googletagmanager.com; img-src 'self' data: https:; style-src 'self' 'unsafe-inline'; connect-src 'self' https://www.google-analytics.com; frame-ancestors 'none'; report-uri /csp-report" always;

# 段階2：強制モードに切り替え
add_header Content-Security-Policy
  "default-src 'self'; script-src 'self' 'nonce-$request_id' https://www.googletagmanager.com; img-src 'self' data: https:; style-src 'self' 'unsafe-inline'; connect-src 'self' https://www.google-analytics.com; frame-ancestors 'none'; base-uri 'self'; form-action 'self'" always;

nonceとhashの使い分け

'unsafe-inline' を許可するとインラインスクリプト全般が通ってしまい、XSS対策としてのCSPはほぼ無意味になります。代わりに、正規のインラインスクリプトだけを通す手段が2つあります。

• nonce：リクエストごとにランダムな値を生成し、ヘッダーとscriptタグの両方に付ける。SSRやテンプレートエンジンで動的にHTMLを生成できる場合に向く。値は毎回変える必要があり、静的HTMLやCDNキャッシュとは相性が悪い。
• hash：インラインスクリプトの内容のSHA-256などをヘッダーに列挙する。内容が固定の静的サイトに向くが、スクリプトを1文字変えるたびに再計算が必要。

Next.jsのようにビルド時にインラインスクリプトが差し込まれるフレームワークはnonceを前提にした仕組みを用意しており、Astroのような静的サイトではhashか、そもそもインラインを使わない設計が現実的です。

HSTSとpreloadの「解除できない」リスク

preloadリストに載るとブラウザに焼き込まれる

HSTSは初回アクセス時にヘッダーを受け取って初めて効くため、「最初の1回」は無防備です。これを埋めるのがpreloadで、hstspreload.orgに申請すると、ChromeやFirefoxなどのブラウザ本体にドメインが組み込まれ、初回からHTTPSが強制されます。申請条件は、max-ageが1年以上、includeSubDomainsとpreloadディレクティブがあること、そしてすべてのサブドメインがHTTPSで応答できることです。

問題は解除の難しさです。リストからの削除申請は可能ですが、各ブラウザのリリースに反映されて全ユーザーに行き渡るまで数か月以上かかります。その間、HTTPでしか動かない社内ツールのサブドメインや、証明書を用意していない古いサブドメインは、preloadに載った瞬間からブラウザに拒否されます。includeSubDomains＋preloadは、そのドメイン配下のすべてを永続的にHTTPS化する覚悟を決めてから付けてください。まずはpreloadなし・短いmax-age（数日）で運用し、問題がなければmax-ageを1年に伸ばし、それでも問題がなければpreloadを検討する、という順番が安全です。

Nginx・Next.js・Astroでの設定例と確認

Nginxで一括付与する

アプリケーションに手を入れずに全レスポンスへ付与できるため、まずはリバースプロキシで設定するのが手軽です。add_headerはlocationブロックに1つでもadd_headerがあると上位の設定を継承しないため、共通のincludeファイルにまとめて各locationで読み込むのが安全です。NginxでのHTTPS化が済んでいる前提の設定です。

# /etc/nginx/snippets/security-headers.conf
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
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;
add_header Permissions-Policy "camera=(), microphone=(), geolocation=()" always;

# server / location 側
server {
    listen 443 ssl;
    include snippets/security-headers.conf;
    location /api/ {
        include snippets/security-headers.conf;   # ここで再includeしないと消える
        proxy_pass http://app;
    }
}

Next.jsとAstroでの設定

// next.config.js（全パスに付与）
const securityHeaders = [
  { key: 'Strict-Transport-Security', value: 'max-age=31536000; includeSubDomains' },
  { key: 'X-Content-Type-Options', value: 'nosniff' },
  { key: 'X-Frame-Options', value: 'DENY' },
  { key: 'Referrer-Policy', value: 'strict-origin-when-cross-origin' },
];
module.exports = {
  async headers() {
    return [{ source: '/(.*)', headers: securityHeaders }];
  },
};
// CSPのnonceはmiddleware.tsで生成し、x-nonceヘッダー経由でレイアウトに渡す

// Astro（Node/SSRアダプタ利用時）: src/middleware.ts
import { defineMiddleware } from 'astro:middleware';
export const onRequest = defineMiddleware(async (_ctx, next) => {
  const res = await next();
  res.headers.set('X-Content-Type-Options', 'nosniff');
  res.headers.set('X-Frame-Options', 'DENY');
  res.headers.set('Referrer-Policy', 'strict-origin-when-cross-origin');
  return res;
});
// 静的ビルドの場合はミドルウェアが動かないので、配信側（Nginx・CloudFront・Cloudflare）で付与する

設定の確認

設定後は securityheaders.com にURLを入力すると、各ヘッダーの有無と評価が表示されます。手元では curl -I で確認できます。CSPはブラウザの開発者ツールのConsoleに違反が出るので、主要な画面を一通り操作して赤字が出ないか見てください。

curl -sI https://example.com/ | grep -iE 'strict-transport|content-security|x-frame|x-content-type|referrer-policy|permissions-policy'

トラブル事例：CSP導入後に決済フォームが動かなくなった

症状：CSPを強制モードにした翌日から、決済ページのカード入力欄が表示されず、購入が止まった。開発環境では問題なかった。
原因：決済サービスのカード入力フォームはiframeで埋め込まれ、さらにそのスクリプトを外部ドメインから読み込んでいた。Report-Only期間中にテストした画面に決済ページが含まれておらず、frame-srcとscript-srcに決済サービスのオリジンが入っていなかった。開発環境では決済をモックしていたため再現しなかった。
対処：ブラウザのConsoleに出た違反メッセージから必要なオリジンを特定し、frame-srcとscript-srcとconnect-srcに追加。あわせてReport-Onlyの収集期間中に「全画面・全操作を網羅するチェックリスト」を作り、決済・外部認証・チャットウィジェットなど外部埋め込みのある画面を必ず含めるルールにした。強制モード切り替え後も一定期間はreport-uriを残し、本番で違反が出たらSlackに通知するようにしています。

まとめ

セキュリティヘッダーは、脆弱性が突かれたときの被害をブラウザ側で限定する二次防御です。nosniff・X-Frame-Options・Referrer-Policy・Permissions-Policyは副作用がほぼなくすぐに付けられ、HSTSはmax-ageを短くから始めてpreloadは慎重に、CSPはReport-Onlyで違反を集めてnonce/hashに置き換えてから強制する、という順序で進めてください。Nginxで一括付与するか、フレームワークの設定で付けるかは構成次第ですが、いずれもsecurityheaders.comとcurlで結果を確認する習慣をセットにします。Webアプリのセキュリティ強化を体系的に進めたい場合は、Harmonic Societyのシステム開発・インフラ支援にご相談ください。