Webサイトのセキュリティを自分でチェックするためにまず見るべき5項目
投稿日:2026.06.09
CATEGORY
- Web開発
セキュリティ事故が発覚するのは、たいていの場合「問い合わせフォームから不審な通知が届いた」や「検索結果に警告が表示された」というタイミングです。原因を調べると、管理画面のパスワードを変えたことがなかった、証明書の更新を失念していた、といった初歩的な見落としが起点になっているケースは少なくありません。
専任のセキュリティ担当がいなくても、少なくとも次の5項目は自力で確認できます。すべてを完璧にすれば攻撃を防げるわけではありませんが、「どこに穴があるか把握している状態」と「把握していない状態」では、事故が起きた後の対応速度もまったく変わってきます。
項目1: HTTPS と SSL/TLS 証明書の有効性を確認する
ブラウザのアドレスバーに鍵アイコンが表示されていれば、そのページはHTTPSで暗号化されています。鍵がない、または「安全でない通信」という警告が出ているサイトは、ユーザーとサーバー間の通信が暗号化されておらず、入力された情報が傍受されるリスクがあります。
確認すべき点は2つです。まずサイト全体がHTTPSになっているか。トップページだけHTTPSで、フォームのあるページがHTTPのままになっているサイトは今でもあります。次に、証明書の有効期限が切れていないか。ブラウザで鍵アイコンをクリックすると有効期限を確認できます。無料のLet's Encrypt証明書は90日ごとに更新が必要で、自動更新の設定が崩れていると予告なく期限切れになることがあります。
ウェブサーバーの管理画面やSSL証明書監視サービス(無料のものが複数あります)で定期的に期限を確認する習慣をつけると、失念による失効を防げます。
項目2: 管理画面・ログインページへのアクセス制限を見直す
WordPressであれば /wp-admin、その他CMSでも管理画面のURLは一般に知られています。URLさえ知っていれば誰でもアクセスできる状態になっていると、ブルートフォース攻撃(パスワードの総当たり試行)の標的になりやすくなります。
まず確認するのは、管理画面URLへのIPアドレス制限が設定されているかどうかです。自社のオフィスや自宅のIPアドレスからのみアクセスを許可する設定は、多くのレンタルサーバーやウェブサーバーの設定ファイルで対応可能です。IPが固定でない場合は、VPNを経由させるという方法もあります。
次に、**多要素認証(MFA)**が有効になっているか確認します。パスワードが流出しても、SMS認証やアプリ認証が有効であれば、不正ログインの成功率は大幅に下がります。主要なCMSには管理画面にMFAを追加するプラグインやモジュールが存在します。
管理画面のURLをデフォルトから変更する対策もよく紹介されますが、それ単体では「URLを秘密にしている」程度の効果にとどまります。IP制限またはMFAと組み合わせて初めて有効な対策になります。
項目3: CMS・プラグイン・ライブラリの更新状況を確認する
WordPressのコアや、利用しているプラグイン、JavaScriptライブラリの脆弱性情報は、セキュリティ研究者が発見すると公開されます。攻撃者はその公開情報を元に、更新していないサイトを自動的にスキャンして狙います。
具体的には、次のものが対象です。
- CMSのバージョン: WordPress、Joomla、Drupalなど、管理画面にバージョン番号とアップデート通知が表示されます。放置しているアップデート通知があれば優先的に対応します。
- プラグイン・テーマ: コアより更新頻度が高く、脆弱性が発見されやすい箇所です。利用していないプラグインは有効化していても攻撃対象になり得るため、使わないものは削除します。
- フロントエンドライブラリ: jQueryのような古いバージョンを長期間使い続けているサイトもあります。npm auditやサードパーティの脆弱性スキャンで確認できます。
更新のたびに動作確認が必要なため、ステージング環境を用意してテストしてから本番に反映するのが理想です。ただし更新の手間を理由に放置する方が、リスクははるかに高くなります。
項目4: パスワード・認証情報の管理を点検する
「管理者アカウントのパスワードは担当者しか知らない」という体制は、一見安全に思えますが、情報漏洩のリスクを担当者個人に集中させているだけです。また、長期間変えていないパスワードや、複数のサービスで使い回されているパスワードは、どこか1か所での流出が連鎖的なリスクになります。
組織として見直すべき点を具体的に挙げます。まず、管理者アカウントのパスワードが適切な強度か。12文字以上で英数字・記号を含み、辞書に載っている単語の組み合わせを避けた構成が推奨されています。次に、同じパスワードを複数のサービスで使い回していないか。サーバー管理パネル、DNSプロバイダー、CMS管理画面など、すべてが同じパスワードであれば一点突破で全滅するリスクがあります。
組織として対応するなら、パスワードマネージャーの導入が現実的です。個人の記憶に依存せず、強度の高いパスワードを各サービスで使い分けられます。また、担当者が退職・異動した際にアカウントの権限を見直す運用ルールも、地味ですが重要な管理作業です。
項目5: 公開情報での漏洩・既知脆弱性を自己点検する
自社のドメインやサービスに関連する情報が、外部の公開データベースに出ていないか確認することも、初歩的な点検として有効です。
代表的な確認方法として、Have I Been Pwned(haveibeenpwned.com)があります。これはパスワード流出インシデントで漏洩したメールアドレスやパスワードが収録されている公開データベースで、自社のメールアドレスが流出履歴に含まれているかを無料で検索できます。社内で業務に使っているメールアドレスが登録されていた場合、そのアカウントに設定しているパスワードは変更を優先します。
また、Shodanのような公開情報収集ツール(インターネット接続された機器の情報を検索できる公開サービス)を使うと、インターネット上で公開されているポートやサービスが確認できます。意図せず開放しているポートがないかの確認に使えます。ただし自社サーバーの正規のIPアドレスを調べる目的に限定します。
CVE(共通脆弱性識別子)データベースで、自社が使っているソフトウェアのバージョンに既知の脆弱性が報告されていないかを確認することも有効です。JPCERT/CCのウェブサイトでは日本語で脆弱性情報が公開されており、定期的に確認するだけで新しいリスクへの気づきになります。
ここまでをまとめると
5項目を通じて共通しているのは、「状態を把握しているかどうか」という点です。証明書の期限も、プラグインの更新状況も、漏洩の有無も、確認しなければ問題が起きるまで気づきません。
この5項目はセキュリティ対策の出発点であり、すべてクリアしたからといって攻撃を完全に防げるわけではありません。一方で、初歩的な設定ミスや未更新が起点になっているケースは、公開されている事故事例でも繰り返し報告されています。
まず現状を把握することが先決です。あなたのサイトで「把握していない」が見つかれば、そこから優先して手を入れてください。具体的な対応方法が技術的に難しい場合は、把握した内容を整理した上で専門家や診断ツールに相談するのが、結果として近道になります。

