セキュリティヘッダーは影響の小さい順に4段階で入れる

最初に入れるのは、表示が壊れにくいX-Content-Type-OptionsとReferrer-Policyです。次にX-Frame-OptionsとPermissions-Policy、3段階目にHSTS、最後にCSPを入れます。段階を分けておくと、表示や機能が壊れたときに原因のヘッダーを1つに絞り込めます。

セキュリティヘッダーの推奨値は、OWASPのHTTP Headers Cheat Sheetを基準にし、X-Frame-Optionsだけは自サイト内の枠表示を残せる SAMEORIGIN にしています（OWASPは DENY）。段階1と同時に、ServerヘッダーとX-Powered-Byに出る版の表記も消します。

ヘッダーはどこで付き、ブラウザはどう使うか

セキュリティヘッダーは、アプリ（WordPressなど）、Webサーバー、CDNのどこでも付けられ、ブラウザは手元に届いた応答のヘッダーに従って動作を変えます。ブラウザからは、どこで付いたヘッダーかを区別できません。1つのヘッダーを付ける場所を1か所に決めることが、重複と付け漏れを防ぐ近道です。

各ヘッダーの設定値と推奨値

段階1と2の4つは推奨値がほぼ決まっており、自サイトの使い方と突き合わせれば決められます。HSTSとCSPは、後の節の手順で扱います。

X-Content-Type-Options: nosniff

X-Content-Type-Optionsの値は nosniff だけで、Content-TypeがJavaScriptの種類でないスクリプトと、text/cssでないスタイルシートを読み込ませなくします。Chrome 146の場合、text/plainで返したJavaScriptは、nosniffが無いと実行され、付けると止まります。

入れる前に curl -sI https://example.com/main.js で、主なJavaScriptのContent-Typeを調べます。text/javascript などなら合格で、text/plain などならサーバーのMIMEタイプの設定を先に直します。

Referrer-Policy: strict-origin-when-cross-origin

Referrer-Policyは、リンク先や外部の読み込み先へ、元のページのURLをどこまで伝えるかを決めます。推奨値は、同じオリジンにはURL全体を、別のオリジンには https://example.com/ のようなオリジンだけを伝え、HTTPSからHTTPへは何も送りません。指定が無いときの既定値でもありますが、OWASPは明示するよう勧めています。

URLに会員番号などを含むサイトでは、no-referrer や same-origin も選べます。ただし、Google Maps Platformの公式文書によると、この2つではRefererが送られず、Refererで制限したAPIキーが要求を拒否する場合があります。

X-Frame-Options と frame-ancestors の関係

X-Frame-Optionsは、自サイトのページを他サイトの枠（iframe）の中に表示させない指示で、クリックジャッキングを防ぎます。値は、すべての枠を拒否する DENY と、すべての親が同じオリジンのときだけ許す SAMEORIGIN の2つです。特定のサイトを許す ALLOW-FROM は廃止され、現在のブラウザはこの値を含むヘッダー全体を無視します。

特定のサイトにだけ埋め込みを許す方法は、CSPの frame-ancestors 'self' https://partner.example.jp のような指定です。CSPの仕様（W3C CSP Level 3）は、強制モードのCSPに frame-ancestors があれば、X-Frame-Optionsを無視すると定めています。Chrome 146でも、X-Frame-Options: DENY より frame-ancestors の許可が優先されます。

新旧のブラウザに対応するため、2つは併記できます。WordPressは管理画面やカスタマイザーで自サイトを枠の中に表示し、本体も SAMEORIGIN を付けるため、サーバー側もSAMEORIGINにそろえます。

Permissions-Policy

Permissions-Policyは、カメラ、マイク、位置情報などのブラウザ機能を、そのページと埋め込んだiframeで使えるかを決めます。値は機能ごとに、() で全面禁止、(self) で自サイトだけ、(self "https://map.example.jp") で指定のオリジンにも許可します。旧仕様のFeature-Policyの camera 'none' は、camera=() と書き換えます。

止めるのは、使っていない機能だけです。店舗検索で位置情報を使うなら geolocation=(self) にし、決済でPayment Request APIを使うなら payment は止めません。

付けないヘッダーと、消すヘッダー

X-XSS-Protectionは廃止されたヘッダーで、OWASPは付けないか、付けるなら 0 にするよう勧めています。古いブラウザのXSS検出機能が、安全なサイトにかえってXSSの弱点を生む場合があったためです。ChromiumがVersion 107で廃止したExpect-CTも、付ける必要はありません。

ServerとX-Powered-Byに出る版の表記は、Apacheならhttpd.confの ServerTokens Prod（.htaccessでは不可）で消します。nginxは server_tokens off;、PHPはphp.iniの expose_php = Off です。版を隠すだけでは安全にならないとApacheの公式文書も述べており、WordPressの本体とプラグインの更新のような更新作業を優先します。

Apache、nginx、WordPress、Cloudflareの設定例

段階1と2の4つのヘッダーに、HSTSの最初の値（max-age=300）を加えた設定例です。どの環境でも、404などのエラー応答とリダイレクトにもヘッダーが付く書き方を選ぶことが要点です。

Apache（.htaccess、VirtualHost）

# .htaccess、またはHTTPSのVirtualHostに書く
<IfModule mod_headers.c>
  # アプリが同名のヘッダーを出しても1本になるよう、unsetとalways setを対にする
  Header unset X-Content-Type-Options
  Header always set X-Content-Type-Options "nosniff"
  Header unset Referrer-Policy
  Header always set Referrer-Policy "strict-origin-when-cross-origin"
  Header unset X-Frame-Options
  Header always set X-Frame-Options "SAMEORIGIN"
  Header unset Permissions-Policy
  Header always set Permissions-Policy "camera=(), microphone=(), geolocation=()"
  Header unset Strict-Transport-Security
  Header always set Strict-Transport-Security "max-age=300"
  # PHPの版の表記を消す（PHPの動かし方で入る表が違うため2行とも書く）
  Header unset X-Powered-By
  Header always unset X-Powered-By
</IfModule>

Apacheの Header には、既定の「onsuccess」と「always」の2つの表があります。Apacheが自ら作る404やリダイレクト（RedirectやRewriteRuleの301）では、always の表しか使われず、always の無い指定は付きません（mod_headersの公式文書）。

PHPのヘッダーが入る表は動かし方で違い、mod_phpでは既定の表に、CGIやFastCGI（PHP-FPMなど）では always の表に入ります。Header always set だけではmod_phpでアプリの同名ヘッダーと2本並ぶため、例のように Header unset と対で書くと、どちらの方式でも1本になります。LiteSpeedなどApache互換のサーバーでは扱いが異なる場合があるため、設定後にcurlで本数を確かめます。

.htaccessの指定は、そのフォルダに届いた要求にだけ効き、VirtualHostやコントロールパネルで行うリダイレクトには付きません。HSTSは、変更できるならVirtualHostに書くのが確実です。mod_headersが無効な場合、<IfModule> で囲んだ指定は黙って無視され、囲まない指定は500エラーになります。

nginx

# /etc/nginx/snippets/security-headers.conf（共通の指定を1か所にまとめる）
add_header X-Content-Type-Options "nosniff" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
add_header X-Frame-Options "SAMEORIGIN" always;
add_header Permissions-Policy "camera=(), microphone=(), geolocation=()" always;
add_header Strict-Transport-Security "max-age=300" always;

# HTTPSのserverブロック（証明書などの設定は省略）
server {
    listen 443 ssl;
    server_name example.com;
    server_tokens off;
    include snippets/security-headers.conf;

    location /assets/ {
        add_header Cache-Control "public, max-age=2592000";
        # add_headerを書いた場所では上の指定が消えるため、読み込み直す
        include snippets/security-headers.conf;
    }
}

nginxの add_header は、always が無いと200や301などの決まった応答にしか付かず、404や500には付きません（nginxの公式文書）。また、下の階層に add_header が1つでもあると、上の階層の add_header はすべて引き継がれません。例の /assets/ のように、キャッシュ用のヘッダーを足したlocationでセキュリティヘッダーが消えるのは、このためです。

対策は、共通のファイルを各locationで読み込み直すか、nginx 1.29.3以降（安定版は1.30.0以降）の add_header_inherit merge; をserverブロックに書く方法です。OSの標準パッケージは版が古いことがあるため、nginx -v で確かめてから選びます。アプリが出した同名のヘッダーは置き換わらずに残るので、PHP-FPMなら fastcgi_hide_header X-Frame-Options; のように隠します（リバースプロキシは proxy_hide_header）。

WordPress

サーバーの設定を変えられない場合は、WordPressの wp_headers フィルターで足せます。コードを wp-content/mu-plugins/ の直下に置くと自動で読み込まれ、テーマの変更でも消えず、管理画面から無効にもできません。

<?php
// wp-content/mu-plugins/security-headers.php として保存する
add_filter( 'wp_headers', function ( $headers ) {
    $headers['X-Content-Type-Options'] = 'nosniff';
    $headers['Referrer-Policy']        = 'strict-origin-when-cross-origin';
    $headers['X-Frame-Options']        = 'SAMEORIGIN';
    $headers['Permissions-Policy']     = 'camera=(), microphone=(), geolocation=()';
    return $headers;
} );

このフィルターは、公式リファレンスにあるとおりWP::send_headers()の中で適用され、効くのは公開ページの応答だけです。管理画面、ログイン画面、REST API、画像やCSSには付かないため、HSTSはサーバーかCDNで付けます。

WordPress 6.9以降は、管理画面とログイン画面に、本体が X-Frame-Options: SAMEORIGIN と frame-ancestors 'self' のCSPを付けます。サーバー側でCSPを付けるときは、この2つの画面でも値が食い違わないかの確認が必要です。

Cloudflare

Cloudflareでは、Rules Overviewの「Create rule」から「Response Header Transform Rule」を作ります。操作は、同名のヘッダーを上書きする「Set static」を選びます。「Add」は既存のヘッダーを残したまま足すため、オリジンの値と2本並びます。

HSTSは、Edge Certificatesの画面にある専用の設定で付けられます。マネージド変換の「Add security headers」は、OWASPが勧めない X-XSS-Protection: 1; mode=block や廃止済みのExpect-CTも付けるため、個別のルールで付ける方が推奨値にそろえやすくなります。

HSTSの設定方法と、max-ageを延ばす手順

HSTSは、HTTPSがサイト全体で安定してから、max-ageを5分、1週間、1か月と延ばし、最後に1年以上にします。HSTSを覚えたブラウザでは、証明書の期限切れなどのエラーのとき、利用者が警告を越えて進めなくなります。そのため、証明書の更新の自動化を先に済ませます。

HSTSを受け取ったブラウザは、受け取った時点からmax-ageの秒数だけそのホストを覚え、HTTPのURLもHTTPSに切り替えて接続します（RFC 6797）。HTTPの応答に付けたHSTSは無視されるため、HTTPSの応答に付けます。

1. 前提をそろえる全ページがHTTPSで表示され、混在コンテンツが無く、HTTPからHTTPSへ301で転送していることを確かめます。証明書の自動更新と期限の監視も整えます。期限の確かめ方は、SSL/TLS証明書のチェック方法で説明しています。
2. サブドメインを含めるか決めるincludeSubDomainsは、社内向けを含むすべてのサブドメインがHTTPSで動く場合だけ付けます。付けるなら、登録窓口のhstspreload.orgが勧める手順のとおり、最初の5分の段階から付けて試します。
3. max-age=300で配信する全ページと各サブドメインを開き、問い合わせ、決済、ログインまで動かします。
4. 1週間、1か月と延ばす604800、2592000の順に延ばします。各段階では、その値の期間が過ぎるまで待ってから次へ進みます。
5. 1年以上にする最終値は31536000（1年）以上にします。OWASPとhstspreload.orgの例は63072000（2年）です。

# 段階ごとの値（includeSubDomainsは、付けると決めた場合だけ）
Strict-Transport-Security: max-age=300; includeSubDomains
Strict-Transport-Security: max-age=604800; includeSubDomains
Strict-Transport-Security: max-age=2592000; includeSubDomains
Strict-Transport-Security: max-age=31536000; includeSubDomains

CSPの設定例と、Report-Onlyからの段階導入

CSPは、まずContent-Security-Policy-Report-Onlyという名前で配信して違反を集め、正当な取得元を許可リストに足します。違反が出なくなったら、ヘッダー名をContent-Security-Policyに変えて強制します。Report-Onlyは読み込みを何も止めないので、本番のサイトで影響だけを測れるのが利点です。

1. Report-Onlyで配信する最初は、自サイト以外の取得元を違反として記録するだけの方針にします（下の設定例）。
2. 全ページを巡回して違反を集めるトップ、記事、フォーム、決済、管理画面まで開き、Consoleの違反を記録します。
3. 許可リストを直すアクセス解析、フォント、地図、動画などの取得元を、必要なディレクティブにだけ足します。
4. ヘッダー名を変えて強制する違反が出なくなったら、Content-Security-Policyに切り替えます。さらに厳しくする案は、Report-Onlyで同時に送って試せます。
5. nonceかハッシュで厳しくするインラインスクリプトを許す 'unsafe-inline' を外し、web.devが勧める厳格なCSPへ近づけます。

# Apache（行末の\は次の行へ続く印。\の後ろに空白を入れない）
Header always set Content-Security-Policy-Report-Only "default-src 'self'; \
    img-src 'self' data: https:; object-src 'none'; base-uri 'self'; \
    form-action 'self'; frame-ancestors 'self'"

# nginx（serverブロックに書く。長い値は変数に分けて組み立てる）
set $csp "default-src 'self'; img-src 'self' data: https:; ";
set $csp "${csp}object-src 'none'; base-uri 'self'; ";
set $csp "${csp}form-action 'self'; frame-ancestors 'self'";
add_header Content-Security-Policy-Report-Only $csp always;

default-srcが代わりを務めるのは、script-srcやimg-srcなどの取得系の指定だけです。base-uri、form-action、frame-ancestorsは個別に書きます。object-src 'none' はプラグインによる埋め込みを止める指定で、web.devの推奨にも含まれる値です。

Chrome 146では、違反はConsoleに情報（Info）として表示され、末尾に『The policy is report-only』で始まる一文が付きます。強制に切り替えると同じ違反がエラーになり、末尾は『The action has been blocked.』に変わります。インラインスクリプトの違反に示される『sha256-…』の値をscript-srcに足すと、そのスクリプトだけを許可できます。

違反をサーバーに集めるには、受け口を Reporting-Endpoints ヘッダーで示し、ポリシーに report-to を足します。設定例はMDNのContent-Security-Policy-Report-Onlyにあり、古いブラウザ向けに report-uri も併記しています。受け口には、ブラウザが送るJSONを保存する仕組みが別に要ります。

強制に切り替えた後は、web.devが勧める厳格なCSPへ近づけます。web.devは、ドメインを並べる許可リスト方式は多くの構成で回避されうるとし、nonce（応答ごとの乱数）かハッシュで許可する方式を勧めています。nonceは暗号学的に安全な乱数（128ビット以上が望ましい）で、応答のたびに作り直します。

# web.devが勧める厳格なCSP（{RANDOM}は応答ごとに作る乱数）
Content-Security-Policy: script-src 'nonce-{RANDOM}' 'strict-dynamic';
    object-src 'none'; base-uri 'none';

# HTML側は、許可するscriptタグに同じ値を付ける
<script nonce="{RANDOM}" src="/js/app.js"></script>

同じヘッダーが2本届いたときに起きること

同名のヘッダーが2本届いたときの扱いはヘッダーごとに違い、HSTSは最初の1本だけ、CSPは両方が効いて厳しい側が勝ちます。X-Frame-Optionsは値が食い違うと、同じサイトの枠の中でも表示を拒否します。重複はエラーにならず黙って起きるため、確認の段階で本数を数えます。

根拠をChrome 146の動作とした行は、他のブラウザで扱いが異なる場合があります。重複を残さないことが、どのブラウザでも確実な対策です。

X-Frame-Optionsの値が食い違うと、Chrome 146はConsoleに次の例のように表示し、DENYとして扱います。

Refused to display 'https://example.com/' in a frame because it set multiple
'X-Frame-Options' headers with conflicting values ('DENY, SAMEORIGIN').
Falling back to 'deny'.

主な原因は、アプリとサーバーによる二重の付与と、Apacheの Header add やCloudflareの「Add」のような追加の操作です。付ける場所を1つに絞り、操作はsetにそろえます。

設定できたかをcurlと開発者ツールで確かめる

確認は設定ファイルではなく、外から取った実際の応答で行います。トップページ、存在しないURL、HTTPSのリダイレクト、画像やCSS、ログイン画面の5種類で、各ヘッダーが1本ずつ付いていれば合格です。

# ヘッダーだけを取得する（-IはHEADリクエスト）
curl -sI https://www.example.com/
# GETで取得し、応答ヘッダーだけを表示する
curl -s -D - -o /dev/null https://www.example.com/
# 404の応答にも付いているか
curl -sI https://www.example.com/no-such-page/
# wwwへ転送するリダイレクトに、HSTSが付いているか
curl -sI https://example.com/ | grep -i -E '^(HTTP|location|strict-transport)'
# 重複していないか（1なら合格）
curl -sI https://www.example.com/ | grep -ci '^x-frame-options:'
# Windows PowerShell 5.1は curl.exe と書き、findstrで絞る
curl.exe -sI https://www.example.com/ | findstr /i "x-frame-options"

Windows PowerShell 5.1では curl がInvoke-WebRequestの別名のため、.exe まで書きます。HEADとGETで違う応答を返すサーバーもあるので、GETの結果も見ておくと確実です。

• トップページ（200）に、入れたヘッダーがそれぞれ1本ずつ付いている
• 存在しないURL（404）にも、同じヘッダーが付いている
• wwwの有無をそろえる転送など、HTTPSのリダイレクトにHSTSが付いている
• 画像、CSS、JavaScriptにも付き、Content-Typeが種類どおりになっている
• ログイン画面や管理画面で、X-Frame-OptionsやCSPの値が食い違っていない

ブラウザでは、F12キーで開発者ツールを開き、Network（ネットワーク）タブで再読み込みします。先頭の文書を選んでHeaders（ヘッダー）のResponse Headers（レスポンス ヘッダー）を見て、CSPの違反はConsole（コンソール）タブで確かめます。

主なヘッダーをまとめて確かめるには、無料のWebサイトのセキュリティチェックも使えます。URLを入れると、HSTSの有無と有効期間、サブドメインへの適用、CSP、X-Frame-Optionsなど6種類のヘッダーを確認し、AからFの判定と直し方を表示します。ヘッダー以外の確認項目は、Webサイトのセキュリティチェック項目の一覧にまとめています。

表示や機能が壊れたときの戻し方

CSP、X-Frame-Options、Permissions-Policyは、設定を戻せば次の読み込みから元に戻ります。HSTSだけは、ブラウザが覚えた期間が残るため、すぐには戻せません。

ヘッダーの設定を1つのファイルにまとめて変更の履歴を残すと、1行の変更で戻せます。影響範囲を見極めにくい場合や、原因のヘッダーを切り分けられない場合は、診断や設定についての相談窓口からお問い合わせください。

よくある質問

関連記事

関連記事Webサイトのセキュリティチェック項目30選｜確認方法つき一覧表 関連記事SSL/TLS証明書のチェック方法｜有効期限・チェーン・通信方式の確認手順 関連記事WordPressの脆弱性を確認する方法｜本体・プラグインの更新と対処の手順 関連記事簡易チェックと脆弱性診断の違い｜無料ツールでできることと、専門業者が必要な場面

The post セキュリティヘッダーの設定方法｜HSTS・CSPの設定例つき first appeared on 総合デジタルマーケティング企業 エスライン・テクノロジーズ.

セキュリティチェックの30項目は、外から17、管理画面と契約で13を確かめる

セキュリティチェックの30項目は、確かめる場所で2つに分かれます。公開ファイル、通信、HTTPヘッダー、DNSの17項目は外から、更新、ログイン、運用の13項目は管理画面と契約書で確かめます。

外から確かめられる設定は、攻撃者にも同じように見えています。証明書の期限切れや公開されたファイルは、URLを知っていれば誰でも気づけます。

管理画面の項目は外から見えないため、無料ツールでは確かめられません。IPAの『安全なウェブサイトの運用管理に向けての20ヶ条』も、パスワード、アカウント、ログといった運用の条項を多く含みます。

今日15分でできる最初の点検

最初の15分は、見つかったときの被害が大きい5点に絞ります。ブラウザとCMSの管理画面があれば、専門の道具は要りません。

1. 公開ファイルを開いてみる(2分)ブラウザで自社ドメインの /.git/HEAD と /.env を開きます。『見つかりません』や『Forbidden』と出れば合格です。設定値のような文字が表示されたら、ほかの作業より先に項目1の対処へ進みます。
2. 証明書の期限を見る(2分)アドレスバーの鍵アイコンから証明書を開き、有効期限を確かめます。残りが30日を切っていたら、自動更新が動いているかをサーバーの管理画面で見ます。
3. 更新とログインの守りを見る(5分)CMSの管理画面で、本体とプラグインに未適用の更新がないかを見ます。管理者アカウントで2段階認証が有効か、パスワードをほかのサービスと使い回していないかも確かめます。
4. バックアップの最終日を見る(3分)サーバーの管理画面で、最後に取得した日と保存先を確かめます。更新を当てるのは、この確認の後です。
5. 外から見える設定をまとめて診断する(3分)無料のWebサイトセキュリティチェックにURLを入れ、重大度が『緊急』と『高』の指摘だけを書き出します。登録は要らず、通常30秒から90秒で結果が出ます。

ターミナルを使える場合は、次の2行で項目5、6、9、11〜13の応答をまとめて確かめられます。1行目のようにスキームを省くと、curlはhttpで接続します。

curl -I example.com
curl -I https://example.com/

例: 1行目の応答(この形なら項目6は合格)
HTTP/1.1 301 Moved Permanently
Location: https://example.com/

例: 2行目の応答で探すヘッダー
strict-transport-security: max-age=31536000
x-frame-options: SAMEORIGIN
x-content-type-options: nosniff

外から確かめる17項目(公開ファイル、通信、ヘッダー、DNS)

外から確かめる17項目は、ログインせずに、ブラウザ、curl、無料ツールで確かめられます。表は、確認方法と合格の目安、放置の危険、直し方の順に並べています。

公開してはいけないファイルとページ(項目1〜5)

よく使われるファイル名は、URLを推測して機械的に試せます。OWASPの検査ガイド(WSTG-CONF-04)も、.bak などの古い写しがソースコードや認証情報を表示する危険を挙げています。確認は、自社のサイトだけに限ります。

# Apache(.htaccess)の例: .git、.svn、.env を含むURLに404を返す
RedirectMatch 404 /\.(git|svn|env)

# nginxの例: 同じURLへのアクセスを拒否する(403を返す)
location ~ /\.(git|svn|env) {
    deny all;
}

どちらの例も、証明書の自動更新が使う /.well-known/ には影響しません。見つかった後の手順は、.gitや.envが公開されていたときの確認と対処で扱っています。

通信の暗号化と証明書(項目6〜10)

HTTPSは、入力内容を盗み見と書き換えから守る土台です。20ヶ条でも、通信の暗号化は独立した1条になっています。SSL/TLS証明書の詳しい見方は、SSL/TLS証明書のチェック方法で扱っています。

HTTPヘッダーとCookie(項目11〜14)

セキュリティヘッダーは、ブラウザに備わった防御を有効にする設定です。確認はどれも、curl -I の応答を1回見れば済みます。書き方の例は、セキュリティヘッダーの設定方法にまとめています。

APIを公開しているサイトは、Access-Control-Allow-Origin が * や、受け取ったオリジンをそのまま返す設定になっていないかも確かめます。

DNSとメール認証(項目15〜17)

自社ドメインを名乗るなりすましメールは、サイトに触れずに顧客や取引先を狙います。IPAの情報セキュリティ10大脅威2026でも、ビジネスメール詐欺が組織向けの10位に入りました。メール認証は、受け取る側に本物かどうかを判断させる仕組みです。

# Mac、Linux
dig TXT example.com +short
dig TXT _dmarc.example.com +short

# Windows(コマンドプロンプト、PowerShell)
nslookup -type=TXT example.com
nslookup -type=TXT _dmarc.example.com

例: 合格の形(SPFは1行だけ、DMARCはレポートの宛先あり)
"v=spf1 include:_spf.example.net ~all"
"v=DMARC1; p=none; rua=mailto:dmarc-report@example.com"

Gmailの送信者のガイドラインは、すべての送信者にSPFかDKIMを求め、1日5,000件以上を送る送信者にはSPF、DKIM、DMARCのすべてを求めています。コマンドを使わない場合は、ドメイン名を入れるだけのDMARC、SPF、DKIMの無料診断ツールでも設定の状況を確かめられます。

管理画面と契約で確かめる13項目(更新、ログイン、運用)

管理画面と契約で確かめる13項目は、外からは見えませんが、乗っ取りを防げるか、被害から戻れるかを決めます。CMS、サーバー、ドメインの管理画面と、制作会社やサーバー事業者との契約書を手元に置いて確かめます。

ソフトウェアの更新(項目18〜21)

公表された脆弱性には、CVEという共通の番号が付きます。攻撃者はその情報を使い、対策していないシステムを狙います。10大脅威2026でも、『システムの脆弱性を悪用した攻撃』が組織向けの4位でした。

WordPressでの具体的な手順は、WordPressの脆弱性を確認する方法で扱っています。

ログインとアカウント(項目22〜25)

管理画面のパスワードは、ほかで漏れたパスワードの一覧を使って機械的に試されます。20ヶ条も、不正ログインの対策、不要なアカウント、推測されやすいパスワードを、それぞれ独立した条項にしています。CMSだけでなく、サーバー、ドメイン、DNS、メール配信の管理画面も同じ扱いです。

バックアップ、監視、体制(項目26〜30)

被害をゼロにはできないため、気づく仕組みと戻す手段を先に用意します。IPAが2026年10月9日に出した不正アクセスによる漏えい等の事案を踏まえた注意喚起も、ログの保持期間、保有データ、外部サービスの見直しを求めています。

直す順番は、被害の大きさ、見つかりやすさ、手間の3つで決める

30項目は、被害の大きさ、見つかりやすさ、直す手間と副作用の3つの物差しで、3段階に分けて直します。被害が大きく機械的に見つかるものから先に直し、表示を壊すおそれのあるものは試しながら進めます。

点検の計画: 今日15分、毎月30分、変更時と年1回の見直し

点検は一度で終わらせず、頻度を決めて回します。目安は、初回15分、毎月30分、変更したときと公開前に10分から20分、四半期に1時間、年1回に半日です。

公開前と変更したときは、次の8点を確かめてから切り替えます。作業の途中で作ったファイルやアカウントは、消し忘れやすいためです。

• 作業で作った .zip、.sql、.bak を消した(項目2)
• テスト用のアカウントと、制作会社の一時的なアカウントを消した(項目25)
• 本番のデバッグ表示を切った。WordPressは WP_DEBUG、PHPは display_errors(項目5)
• テスト環境は、Basic認証などで社外から見えない(項目4)
• 全ページがhttpsで開き、Consoleに混在コンテンツの警告がない(項目6、10)
• curl -I で、ヘッダーが意図どおりに返る(項目11〜13)
• フォームを送信し、WAFに止められず、確認メールが届いた(項目28)
• 新しく作ったサブドメインに、使い終えたら消す担当を決めた(項目17)

問題が見つかったときの初動: 記録、停止、鍵の作り直し、報告

公開ファイルや改ざんが見つかったら、記録、停止、作り直し、調査、報告の判断、再発防止の順で動きます。先にファイルを消すと、調査と報告に要る証拠まで失うためです。

1. 記録を残す見つけた日時、URL、画面のスクリーンショットを残し、サーバーのログを保全します。
2. 公開を止める問題のファイルを公開フォルダから外すか、サーバー設定で拒否します。改ざんであれば、メンテナンス表示に切り替えます。
3. 鍵とパスワードを作り直す読まれたおそれのある .env のパスワード、APIキー、管理者のパスワードを変えます。ファイルを消しても、写しを取られた鍵は使えるままです。
4. ログで範囲を調べるアクセスログで、そのURLに外部から届いたリクエストの有無と日時を確かめます。
5. 報告と通知の要否を判断する個人データが漏れたおそれがあれば、個人情報保護委員会への報告と本人への通知が必要かを判断します。
6. 再発を防ぐ原因になった手順、権限、更新の漏れを直し、点検の計画に組み込みます。

自社だけで判断が難しい場合は、制作や保守を担う会社に早めに連絡します。診断結果の読み方や直す順番の相談は、エスライン・テクノロジーズのお問い合わせ窓口でも受け付けています。

IPAの20ヶ条と、この点検表の対応

この30項目は、IPAの20ヶ条の観点を、小規模なサイトで確かめられる形に置き換えたものです。20ヶ条は2005年に掲載が始まり、2015年の全面改訂を経て、2019年3月6日に最終更新されています。

20ヶ条の3条目にある『安全なウェブサイトの作り方』の脆弱性対策は、入力フォームなどの作りを調べる必要があり、この点検表には含めていません。ただし、項目11〜14のヘッダーとCookieは、その被害を和らげる設定にあたります。

反対に、メール認証(項目15、16)、参照先のないCNAME(項目17)、証明書の自動更新(項目7)は、20ヶ条にない観点として加えました。メールの送信者への要件や、証明書の有効期間の短縮といった、最終更新後の変化に対応するためです。

無料ツール、手作業、専門家の診断の使い分け

外から見える項目は無料ツールでまとめて確かめ、管理画面の項目は自分の目で確かめます。入力フォームや会員機能の作りは、専門家の脆弱性診断が担う領域です。

手順5で使った無料ツール『Security Checker X』は、公開ページの取得、DNSの照会、TLSの接続確認だけで診断し、ログインの試行や攻撃用データの送信はしません。各指摘には『確認済み』『推定』『可能性』の確度が付くため、事実と推測を分けて読めます。診断できるのは、自社か管理権限のあるサイトだけです。

専門家に依頼するかどうかの判断は、簡易チェックと脆弱性診断の違いで整理しています。

よくある質問

項目ごとに詳しく確かめる関連記事

関連記事.gitや.envが公開されていないか確認する方法と、見つかった時の対処 関連記事SSL/TLS証明書のチェック方法 関連記事セキュリティヘッダーの設定方法 関連記事WordPressの脆弱性を確認する方法 関連記事簡易チェックと脆弱性診断の違い

The post Webサイトのセキュリティチェック項目30選｜確認方法つき一覧表 first appeared on 総合デジタルマーケティング企業 エスライン・テクノロジーズ.