この記事で分かること
- 経営者やWeb担当者が確認したい30項目と、その見方
- 放置した場合に起こり得ることと、確認の方法
- どの項目から直すかの優先順位
- 外から見える範囲を、無料の診断ツールで確かめる方法
要点を先に書きます。外から確認できる弱点は、通信の暗号化と証明書、HTTPヘッダー、Cookie、ページの内容、公開ファイル、ソフトウェアの更新、DNSとメール認証の七つに分けて点検できます。下の表は、そのまま社内の点検表に使えます。最初に手を付けるなら、公開ファイルと証明書です。
セキュリティチェックでは何を確認するのか
ここでいうセキュリティチェックは、サイトの外から観察できる設定と更新状況を確かめる作業です。ログイン不要で確認できる範囲、つまり証明書、HTTP応答の設定、公開ファイル、ソフトウェアの版、DNSの設定が対象です。
入力フォームへ攻撃用の文字列を送るような検査は、脆弱性診断やペネトレーションテストの領域で、専門家に依頼するのが一般的です。違いは、簡易チェックと脆弱性診断の違いで整理しています。
脆弱性とは、攻撃に悪用され得る設定や実装の弱点です。公開された脆弱性には、CVEという識別番号が付きます。
セキュリティチェック項目一覧（30項目）
「放置の危険」は、その状態が続いたときに起こり得ることです。実際の影響は、サイトの種類や他の対策で変わります。
通信の暗号化と証明書（4項目）
| 項目 | 何を見るか | 放置の危険 | 確認方法 |
|---|---|---|---|
| 1. HTTPSで表示される | 全ページが https:// で開くか。ログインとフォームは特に | 入力内容が途中で読まれ、書き換えられる。「保護されていない通信」と表示される | アドレスバー、curl -I https://自社ドメイン/ |
| 2. 証明書の期限と名前 | 証明書が期限内か。wwwの有無やサブドメインも含むか | ブラウザが全画面で警告し、訪問者が先へ進めない | 鍵アイコンから証明書を表示。詳細は証明書の確認方法 |
| 3. 古い通信方式の無効化 | TLS 1.0と1.1、SSL 3.0を受け付けないか | 弱点の知られた方式で通信させられる。TLS 1.0と1.1はRFC 8996で廃止された | 診断ツールの結果 |
| 4. HTTPからの転送 | http:// で開くと https:// へ転送されるか | http側から入った訪問者が、暗号化されない通信を続ける | curl -I http://自社ドメイン/ |
HTTPヘッダー（8項目）
確認は、curl -I https://自社ドメイン/ の出力か、開発者ツールのNetworkタブで行います。設定コードはセキュリティヘッダーの設定方法にあります。
| 項目 | 何を見るか | 放置の危険 | 確認方法 |
|---|---|---|---|
| 5. HSTS | Strict-Transport-Security があり、max-age が十分か | 暗号化されない接続へ誘導される余地が残る | 応答ヘッダー |
| 6. CSP | Content-Security-Policy で、読み込める取得元を絞っているか | XSSが成立したとき、外部スクリプトを止められない | 応答ヘッダー |
| 7. X-Frame-Options | 他サイトのフレーム内に表示されないか（CSPの frame-ancestors でも可） | 操作を横取りするクリックジャッキングを受ける | 応答ヘッダー |
| 8. X-Content-Type-Options | nosniff が付いているか | 画像として置いたファイルを、スクリプトとして扱われる余地が残る | 応答ヘッダー |
| 9. Referrer-Policy | 他サイトへ移動するとき、元のURLをどこまで伝えるか | URLに含まれる会員番号や検索語が、外部に渡る | 応答ヘッダー |
| 10. Permissions-Policy | カメラや位置情報などの機能を、必要なものに絞っているか | 埋め込んだ外部コンテンツが、不要な機能を使える | 応答ヘッダー |
| 11. Server、X-Powered-By | Apache/2.4.x、PHP/8.x のような版を出していないか | 既知の脆弱性を狙う手がかりになる | 応答ヘッダー |
| 12. CORS | Access-Control-Allow-Origin が、* や受け取ったオリジンの反映など、広すぎないか | 他サイトのスクリプトに、利用者のデータを読まれる場合がある | APIなどのURLの応答ヘッダー |
Cookie（3項目）
確認は、開発者ツールのApplicationタブか、curl -I のSet-Cookie行で行います。
| 項目 | 何を見るか | 放置の危険 | 確認方法 |
|---|---|---|---|
| 13. Secure | Secure 属性が付いているか | HTTPの通信にもCookieが乗り、盗み見られる | Set-Cookie行 |
| 14. HttpOnly | JavaScriptから読めない属性か | XSSで、ログイン状態のCookieが盗まれる | Set-Cookie行 |
| 15. SameSite | Lax か Strict が明示されているか | 他サイトからの操作にCookieが付き、意図しない操作（CSRF）を受ける | Set-Cookie行 |
ページの内容（3項目）
| 項目 | 何を見るか | 放置の危険 | 確認方法 |
|---|---|---|---|
| 16. 混在コンテンツ | HTTPSのページが、http:// の画像やスクリプトを読んでいないか | スクリプトやCSSはブロックされて表示が崩れ、画像は途中で差し替えられる恐れがある | 開発者ツールのConsole |
| 17. 外部スクリプトのSRI | 外部CDNの script や link に integrity 属性があるか | 配信元が改ざんされると、自社サイト上で実行される | ページのソースで integrity を検索 |
| 18. 秘密情報とソースマップ | HTMLやJavaScriptに、APIキーやトークン、.map ファイルが残っていないか | 鍵が悪用され、元のソースコードが復元される | ページのソース、.map のURL |
公開されているファイル（5項目）
確認は自社サイトのURLだけに限ります。.git と .env は、公開を確かめる記事でも扱っています。
| 項目 | 何を見るか | 放置の危険 | 確認方法 |
|---|---|---|---|
| 19. .git フォルダ | /.git/HEAD が取得できるか | ソースコードと変更履歴が取り出される | /.git/HEAD を開き「ref: refs/heads/」が出たら公開 |
| 20. .env などの設定ファイル | /.env が取得できるか | DBのパスワードやAPIキーが読み取られる | /.env を開き KEY=値 の行が出たら公開 |
| 21. バックアップ、SQLダンプ | backup.zip、dump.sql、index.php.bak などが公開領域にないか | 全データや設定がダウンロードされる | FTPやファイルマネージャで確認 |
| 22. 一覧表示、情報ページ | ディレクトリ一覧、phpinfo、サーバー状態ページが出ないか | 構成や版が分かり、次の攻撃の手がかりになる | フォルダのURLをブラウザで開く |
| 23. WordPressの公開情報 | readme.html、xmlrpc.php、/wp-json/wp/v2/users が見えるか | 版やログインIDが分かり、総当たり攻撃の手がかりになる | 各URLを開く。詳細はWordPressの脆弱性の確認方法 |
ソフトウェアの更新（3項目）
| 項目 | 何を見るか | 放置の危険 | 確認方法 |
|---|---|---|---|
| 24. Webサーバー、PHP | 版が、提供元のサポート期間内か | 修正の出ない版に、既知の脆弱性が残る | サーバーの管理画面。PHPは公式のサポート期間表 |
| 25. CMS、プラグイン、テーマ | 本体、プラグイン、テーマが最新か。更新が止まっていないか | 公表済みの脆弱性を狙われる。悪用が確認されたものはCISAのKEVカタログにある | 管理画面の更新画面 |
| 26. JavaScriptライブラリ | jQueryなどの版が古くないか | 既知のXSSなどが残る | コンソールで jQuery.fn.jquery |
DNSとメール認証（4項目）
確認は、dig（Windowsではnslookup）か、DNSの管理画面で行います。メール認証の詳しい診断は、DMARC・SPF・DKIM診断ツールも使えます。
| 項目 | 何を見るか | 放置の危険 | 確認方法 |
|---|---|---|---|
| 27. SPF | ドメインのTXTに、送信を許可するサーバーが書かれているか | なりすましメールが、受信側で見抜かれにくい | dig TXT 自社ドメイン |
| 28. DKIM | 電子署名の公開鍵が、DNSに登録されているか | メールの改ざんを、受信側が検知できない | セレクタ名が要るため、メール配信サービスの管理画面で見る |
| 29. DMARC | _dmarc.自社ドメイン のTXTに、ポリシーがあるか | なりすましメールの扱いが受信側任せで、レポートも届かない | dig TXT _dmarc.自社ドメイン |
| 30. 参照先のないCNAME | 解約したサービスを指すCNAMEが残っていないか | サブドメインを第三者に乗っ取られる | DNSの管理画面で確認 |
どこから直すか：優先順位のつけ方
30項目を一度に直す必要はありません。次の順に進めると、手戻りが少なく済みます。
- 公開されてはいけないファイル（項目19〜21）。取得できる状態なら、まずファイルを取り除きます。読まれた可能性のあるパスワードやキーは、作り直します。
- 証明書とHTTPS（項目1〜4）。期限切れは、サイトが開けなくなる直接の原因です。更新が自動かも確認します。
- ソフトウェアの更新（項目24〜26）。公表された脆弱性は、その情報をもとに狙われます。
- ヘッダーとCookie（項目5〜15）。表示が崩れる場合があるため、影響の小さいものから入れます。
- メール認証（項目27〜30）。なりすましの被害は、取引先や顧客に及びます。
無料の診断ツールで、外から見える範囲を確かめる
表のうち、外から観察できる項目は、診断ツールで一度に確かめられます。Security Checker Xは、URLを入力すると、証明書、HTTPヘッダー、Cookie、公開ファイル、ソフトウェアの更新、DNSとメール認証を診断します。登録は不要で、30秒から90秒ほどで結果が出ます。
診断は、公開ページの取得、DNSの照会、TLSの接続確認だけで行い、ログインの試行や攻撃用データの送信はしません。各指摘には、観察できた根拠と、「確認済み」「推定」「可能性」の確度が付くため、事実と推測を区別して読めます。対象にできるのは、自社のサイトか、許可を得たサイトだけです。
よくある質問
セキュリティチェックは、どのくらいの頻度で行えばよいですか？
決まった頻度はありません。サーバーの移転、証明書の更新、プラグインの追加など、サイトに手を入れた直後と、月に一度ほどの定期確認が目安です。
取引先など、他社のサイトを調べてもよいですか？
管理者の許可がない他社サイトの調査は避けてください。公開ページを読むだけでも、相手のサーバーには記録が残り、攻撃の下調べと区別がつきません。
すべての項目に問題がなければ、安全だといえますか？
いいえ。この一覧は、外から観察できる設定と更新状況の確認です。入力値の扱いの不備のようなアプリ固有の脆弱性や、ログイン後の画面は確認できません。重要なサイトでは、専門家による脆弱性診断を併用してください。
セキュリティヘッダーを追加すると、サイトが壊れることはありますか？
あります。特にCSPは、アクセス解析や広告、埋め込み動画の読み込みを止めることがあります。違反だけを報告するReport-Onlyで影響を見てから、適用します。
小さな会社のサイトでも、ここまで必要ですか？
公開サイトは、規模や知名度にかかわらず、自動の探索の対象になります。ただし、30項目を完璧にそろえる必要はありません。優先順位の高い項目から、できる範囲で進めてください。
まとめ
まずは、公開されてはいけないファイル（項目19〜21）と、証明書の期限（項目2）の二つを、今日のうちに確かめてください。どちらも数分で終わり、見つかった場合の影響が大きい項目です。残りは、Security Checker Xの結果を見ながら、優先順位の順に進められます。
診断結果の読み方が分からない場合や、設定の変更、更新の運用まで任せたい場合は、ホームページの制作・保守のご相談をお受けしています。
よくある質問
セキュリティチェックは、どのくらいの頻度で行えばよいですか？
決まった頻度はありません。サーバーの移転、証明書の更新、プラグインの追加など、サイトに手を入れた直後と、月に一度ほどの定期確認が目安です。
取引先など、他社のサイトを調べてもよいですか？
管理者の許可がない他社サイトの調査は避けてください。公開ページを読むだけでも、相手のサーバーには記録が残り、攻撃の下調べと区別がつきません。
すべての項目に問題がなければ、安全だといえますか？
いいえ。この一覧は、外から観察できる設定と更新状況の確認です。入力値の扱いの不備のようなアプリ固有の脆弱性や、ログイン後の画面は確認できません。重要なサイトでは、専門家による脆弱性診断を併用してください。
セキュリティヘッダーを追加すると、サイトが壊れることはありますか？
あります。特にCSPは、アクセス解析や広告、埋め込み動画の読み込みを止めることがあります。違反だけを報告するReport-Onlyで影響を見てから、適用します。
小さな会社のサイトでも、ここまで必要ですか？
公開サイトは、規模や知名度にかかわらず、自動の探索の対象になります。ただし、30項目を完璧にそろえる必要はありません。優先順位の高い項目から、できる範囲で進めてください。
関連記事
- セキュリティヘッダーの設定方法｜HSTS・CSPの設定例つき
- WordPressの脆弱性を確認する方法|本体・プラグインの更新と対処の手順
- SSL/TLS証明書のチェック方法|有効期限・チェーン・通信方式の確認手順
- 簡易チェックと脆弱性診断の違い|無料ツールでできることと、専門業者が必要な場面
- .gitや.envが公開されていないか確認する方法と、見つかった時の対処
関連する用語
サイトの設定を無料で確認する
この記事の内容を、自分のサイトで確かめたい時は、Webサイト セキュリティチェッカー「Security Checker X」をお使いください。URLを入力するだけで、登録なしで診断できます。
コメント