NoteStack

This page shows a beginner-friendly, low-risk way to add baseline security headers in Nginx, including how to find your active config file, where to put the directives, and how to verify the results with nginx -t and curl -I.

Nginxで安全に入れられる基本セキュリティヘッダ（ほぼ壊れない）

「セキュリティヘッダを入れたいけど、サイトが壊れるのが怖い」——この不安はとても自然です。ヘッダの中には入れ方を間違えると動作に影響するものがありますが、逆に“ほぼ壊れない”基本セットもあります。

このページでは、まず事故りにくい基本セットを入れて、テスト→反映→確認までを手順化します。個人情報になりやすい部分（ドメイン名など）は example.com で例示します。

このページで扱うこと
このページでは“まだやらないこと”

先に結論：最短で迷わない手順

1) 設定ファイルの場所を確定する
  1. /etc/nginx/nginx.conf の include 行を確認する
  2. /etc/nginx/conf.d/ などにある “仮想ホスト設定” を探す
  3. 最終的に sudo nginx -T で「実際に読まれている設定」から確定する
2) HTTPS側の server { ... } に基本ヘッダを追加

ヘッダはHTTPS側（listen 443 ssl ...）の server ブロックに入れるのが基本です。

3) 反映と確認
  1. sudo nginx -t（文法チェック）
  2. sudo systemctl reload nginx（反映）
  3. curl -I https://example.com/（ヘッダ確認）

設定ファイルがどこにあるか分からないときの探し方

「設定を変えたいけど、どのファイルを編集すればいいか分からない」問題は、入口→include→実体の順で辿ると解決します。

1) 入口（nginx.conf）を確認

sudo ls -l /etc/nginx/nginx.conf
sudo grep -n 'include' /etc/nginx/nginx.conf

よくある例：

include /etc/nginx/conf.d/*.conf;
include /etc/nginx/default.d/*.conf;

2) include先のフォルダを確認

sudo ls -la /etc/nginx/conf.d
sudo ls -la /etc/nginx/default.d

example.conf のようなファイルが並んでいれば、その中に目的のサイト設定（仮想ホスト設定）が入っていることが多いです。

3) 最終確定：Nginxが実際に読んでいる設定を出力して探す

「ファイルはあるけど読み込まれていない」を避けるため、最後はこれが確実です。

sudo nginx -T 2>/tmp/nginx_full_dump.txt
grep -n 'example\.conf' /tmp/nginx_full_dump.txt

ファイル名が分からない場合は、サイトのドメインや root のパスで探すと早いです。

grep -n 'server_name' /tmp/nginx_full_dump.txt
grep -n 'root ' /tmp/nginx_full_dump.txt

補足：ファイル名で全体検索したいとき

sudo find /etc/nginx -type f -name 'sakura.conf' -print

HTTP/2 の listen 443 ssl http2; は問題？

多くの環境で、HTTPSの待ち受けは次のどちらかです。

listen 443 ssl;
listen 443 ssl http2;
結論
http2 が付いていても基本的に問題ありません。HTTPSに加えてHTTP/2も使えるようにする指定です。
安全確認（必須）
環境ごとの差を吸収するため、変更前後は必ず sudo nginx -t を実行します。
sudo nginx -t
nginx -v

“ほぼ壊れない”基本セキュリティヘッダを追加する

ここからが本題です。まずはアプリを壊しにくい基本セットを入れます（CSPはまだ入れません）。

追記する場所

HTTPS側の server { ... } の中で、location より上（root より上だと分かりやすい）に置くのが安全です。

追加するヘッダ（baseline）

# --- Security Headers (baseline / low-risk) ---
add_header X-Content-Type-Options "nosniff" always;
add_header X-Frame-Options "SAMEORIGIN" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
add_header Permissions-Policy "geolocation=(), microphone=(), camera=()" always;

# HSTS: HTTPSを強制（常時HTTPS運用が前提）
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;

それぞれ何を守るの？（やさしい説明）

X-Content-Type-Options: nosniff
ブラウザの「勝手に種類を推測する動き」を止めて、意図しない実行を減らします。
X-Frame-Options: SAMEORIGIN
別サイトにあなたのページを“額縁（iframe）”として埋め込まれにくくします（クリックジャッキング対策）。
Referrer-Policy
リンク移動のとき、相手に渡る情報（参照元URL）を必要最小限にします。
Permissions-Policy
カメラ・マイク・位置情報など、ブラウザ機能の利用を制限します（必要なら後で許可に変更できます）。
Strict-Transport-Security（HSTS）
一度HTTPSでアクセスしたブラウザに「次からはHTTPに戻らないで」と覚えさせます。HTTPS常用のサイトで強力です。

編集→文法チェック→反映

# 例：/etc/nginx/conf.d/example.conf を編集
sudo nano /etc/nginx/conf.d/example.conf

# 文法チェック（ここが最重要）
sudo nginx -t

# 反映（切り替えではなく“再読み込み”）
sudo systemctl reload nginx

確認：curlでヘッダを見る

curl -I https://example.com/

期待する例（抜粋）：

x-content-type-options: nosniff
x-frame-options: SAMEORIGIN
referrer-policy: strict-origin-when-cross-origin
permissions-policy: geolocation=(), microphone=(), camera=()
strict-transport-security: max-age=31536000; includeSubDomains

事故りにくくするための安全ルール

sudo nginx -t が通らないなら、reloadしない
まずは文法エラーを直します。reloadしてしまうと、サイトが落ちる可能性があります。
バックアップを残してから編集する
.bak を残すのは良い習慣です（Nginxは通常 *.conf だけを読み込みます）。
HSTS（Strict-Transport-Security）は「常時HTTPS」が前提
HTTPへ戻す運用がある場合は注意が必要です。迷うなら max-age を短め（例：1日）から始めてもOKです。

チェックリスト（この順でやれば迷わない）

  1. 入口を確認：/etc/nginx/nginx.conf の include を確認
  2. 実体を探す：/etc/nginx/conf.d などの *.conf を確認
  3. 編集前にバックアップ（任意）：cp example.conf example.conf.bak
  4. HTTPS側の server にヘッダを追加（baseline）
  5. sudo nginx -t（成功するまで次へ進まない）
  6. sudo systemctl reload nginx
  7. curl -I でヘッダが出ているか確認

よくある質問（FAQ）

Q. 設定ファイルが多すぎて、どれが本体かわかりません
A. sudo nginx -T で「実際に読み込まれている設定」を出し、ドメイン名（server_name）で検索するのが一番確実です。
Q. listen 443 ssl http2; は消した方がいいですか？
A. 多くの環境では問題ありません。気になる場合は sudo nginx -t に警告が出ていないかを確認してください。
Q. CDNを使っていても、Nginxでヘッダを入れていい？
A. 基本はOKです。ただしCDN側で同じヘッダを追加/上書きしていると結果が変わることがあるので、最後は curl -I で確認します。