いますぐ確認!Webサイトのセキュリティ対策チェックリスト10選
2025.09.15ウェブサイトのセキュリティ対策は、企業の信頼性を守る上で不可欠です。しかし、何から手をつければいいか分からない方も多いのではないでしょうか。
今回は、開発者・管理者向けに、最低限ここは押さえたいという10項目をチェックリストにまとめたものです(2026年9月時点)。
先に、考え方をひとつだけ共有させてください。
IPA(情報処理推進機構)の「安全なウェブサイトの作り方」では、脆弱性への対策を2つに分けています。
- 根本的解決:脆弱性そのものを作り込まない実装にする
- 保険的対策:攻撃されたときの被害を小さくする
保険的対策は、根本的解決が漏れたときのセーフティネットとして有効です。ただし、それだけに頼る設計は推奨されていません。このチェックリストでも、「根本的な対策」と「補助的な対策」を区別して書いています。
サーバー・OSのセキュリティ
1. OS・ミドルウェア・PHPを更新する
サーバーのOS、Webサーバー、データベース、PHPなどは、サポートされている最新の状態に保ちましょう。WordPressの公式ハンドブックも、サーバー側のソフトウェアを安定した最新版に保つよう案内しています。
共用サーバーやレンタルサーバーの場合は、「どこまでが事業者の責任で、どこからが自分の責任か」を確認しておくのがポイントです。WordPress公式ハンドブックにも、ホスティング事業者が守るのはインフラで、利用者が入れたアプリケーション(WordPressやプラグイン)は利用者の責任、という趣旨の記載があります。
2. 使っていないサービスを止め、使うものは暗号化する
使っていないサービスは止めて、攻撃の入口を減らします。
ただし、SSHのように保守で使うものまで止める必要はありません。「止める」のではなく「安全に使う」が正解です。
- FTPは通信が暗号化されないので、SFTP(またはFTPS)に切り替える
- SSHは、パスワード認証より鍵認証を使い、接続元を絞れるなら絞る
- 使っていないポートは閉じる
WordPress公式ハンドブックも、可能な限りSFTPを使うよう案内しています。
サイト自体のセキュリティ
3. サイト全体をHTTPS化する
ユーザーとサーバーの間の通信を暗号化し、盗聴や改ざんを防ぎます。今は「対応しているかどうか」より、「全ページ、管理画面も含めて例外なくHTTPSか」を確認するのが大事です。
- HTTPからHTTPSへ301リダイレクトしている
- 証明書の有効期限切れを監視している(自動更新を推奨)
- 画像やスクリプトなどがHTTPのまま混在していない
4. 管理画面の認証を強くする
パスワードについては、ここ数年で考え方が大きく変わりました。
- 長さを重視する。 NISTの最新ガイドライン(SP 800-63B-4)は、複雑な文字種の組み合わせを強制するより、長いパスワードを推奨しています。目安は15文字以上です。
- 定期的な変更は求めない。 NISTは、流出や侵害が疑われるときを除いて、定期変更を要求してはいけないとしています。日本でも、総務省の「国民のためのサイバーセキュリティサイト」が、定期的な変更は不要としています。頻繁な変更を強制すると、覚えやすい弱いパスワードや使い回しが増えるためです。
- 使い回さない。 サービスごとに別のパスワードを使い、パスワードマネージャーを使えるようにします。
- 2段階認証を有効にする。 WordPressの公式ハンドブックも、強いパスワードに加えて2段階認証を推奨しています。
「管理者のIDをadminにしない」も、簡単で効果があります。WordPress公式でも、攻撃で最初に狙われやすいのがadminやwebmasterといった推測しやすい名前だと説明されています。
5. ログインの試行回数を制限する
総当たり攻撃(ブルートフォース)への対策として、ログインの失敗回数に制限をかけます。
- 一定回数の失敗で、一定時間ロックする
- 管理画面にBasic認証を重ねる、または接続元IPで絞る(
wp-adminをBasic認証で守る場合は、admin-ajax.phpが動かなくなることがあるので注意) - ログイン失敗のアラートを見られるようにしておく
6. WAF(Web Application Firewall)を導入する
WAFは、SQLインジェクションやXSSのような、Webアプリケーションの脆弱性を狙った攻撃を検知・遮断します。クラウド型のWAF、サーバーに入れるModSecurity、WordPress向けのプラグインなどがあります。
ただし、WAFは万能ではありません。WordPressの脆弱性情報を扱うPatchstackの「State of WordPress Security in 2026」では、ホスティング事業者の標準的な防御が、実際に悪用されている脆弱性の攻撃のうち約12%しか防げなかった、と報告されています。
「WAFを入れたからOK」ではなく、あくまで保険として考えましょう。アプリ側の対策と更新が本体です。
フォーム・入力データのセキュリティ
IPAの「安全なウェブサイトの作り方」は、SQLインジェクション、クロスサイト・スクリプティング、CSRFなど11種類の脆弱性を取り上げ、それぞれ根本的解決と保険的対策を示しています。詳しくは同資料を読むのが確実ですが、ここでは特に事故につながりやすい3つを挙げます。
7. XSS(クロスサイト・スクリプティング)対策:出力時にエスケープする
ユーザーが入力した値を画面に表示するときは、表示する場所(HTMLの本文、属性、JavaScript内、URLなど)に合わせてエスケープします。
「入力時にサニタイズ(無害化)する」だけでは不十分です。危険な文字は、表示する場所によって変わるからです。基本は「出力時にエスケープ」で、入力値の検証は補助と考えましょう。
WordPressなら、esc_html()、esc_attr()、esc_url()、wp_kses()などの関数を、出力する場所に応じて使い分けます。
8. CSRF(クロスサイト・リクエスト・フォージェリ)対策:トークンで確認する
ログイン中のユーザーに、本人が意図しないリクエストを送らせる攻撃です。フォームや、状態を変更するリクエストには、推測されにくいトークンを付けて、サーバー側で確認します。
WordPressでは、この役割をNonceが担います。ただし、WordPressのNonceは、本来の意味のNonce(1回限りの値)とは違います。公式ドキュメントに、次の注意点があります。
- 有効期間の間は何度でも使える(1回限りではない)
- CSRFには効くが、リプレイ攻撃は防げない
- ログインしていない訪問者には、全員に同じNonceが発行される
つまり、Nonceは認証・認可の代わりにはなりません。処理の前に、current_user_can()で権限を必ず確認しましょう。「Nonceを付けたから安全」と考えるのは危険です。
9. SQLインジェクション対策:プレースホルダを使う
データベースにアクセスするときは、SQL文を文字列連結で組み立てず、プレースホルダ(プリペアドステートメント)を使います。IPAのチェックリストでも、SQL文の組み立てはすべてプレースホルダで実装する、が根本的解決とされています。
WordPressなら、$wpdb->prepare()を使います。
WordPressのセキュリティ
10. コア・プラグイン・テーマを更新し、使っていないものは削除する
WordPressのセキュリティでいちばん大事なのは、ここです。
Patchstackの報告では、2025年に見つかったWordPress関連の新しい脆弱性は11,334件。そのうち91%がプラグイン、9%がテーマで、WordPress本体(コア)は6件だけでした。つまり、問題の中心は本体ではなく、プラグインとテーマです。
しかも、攻撃までの時間は短くなっています。同じ報告では、集中的に悪用された脆弱性の20%が、公開から6時間以内に悪用されていました。24時間以内では45%、7日以内では70%です。
だから、次のことを習慣にしてください。
- 更新の通知が来たら、なるべく早く適用する(更新前にバックアップを取る)
- 使っていないプラグインとテーマは、無効化ではなく削除する
- 入れる前に、更新が続いているか、評判はどうか、既知の脆弱性がないかを確認する
- 公式ディレクトリ以外の出所が不明なプラグイン・テーマは入れない
なお、更新が公開されていない脆弱性もあります。そういう場合は、WAFやプラグインの一時停止など、緩和策が必要になります。「更新さえしていれば安全」とも言い切れない点は、覚えておいてください。
あわせてやっておきたいこと
10項目の外側にも、事故のときに差がつくポイントがあります。
- バックアップを取り、復元テストをする。 取っているだけで、戻せるか試していないケースは意外と多いです。保存先はサーバーの外にも置きましょう
- ダッシュボードからのファイル編集を無効にする。
wp-config.phpにdefine( 'DISALLOW_FILE_EDIT', true );を書くと、管理画面からテーマやプラグインのPHPを編集できなくなります。WordPress公式ハンドブックによると、侵入した攻撃者が最初に使いがちな機能です。ただし、ファイルをアップロードされる攻撃までは防げません - ファイルのパーミッションを絞る。 書き込みが必要な場所以外は、書き込めないようにします
- 権限を最小限にする。 全員を管理者にせず、投稿者・編集者など役割に合わせたユーザー権限を使います
- ログを残して見る。 ログには、ログインの試行や不審なアクセスの痕跡が残ります。ファイルの変更を検知する仕組みも役に立ちます
効果が限定的な対策:「WordPressであることを隠す」「ログインURLの変更」
WordPressの出力するタグを隠す、ログインURLを変える、といった対策がよく紹介されます。やってはいけないわけではありませんが、主役にしてはいけません。
WordPress公式ハンドブックには、「隠すことによるセキュリティ(security through obscurity)は、主たる対策としては一般的に不適切」という趣旨の記載があります。
理由は、実際の攻撃の多くが、プラグインやテーマの既知の脆弱性を、自動で広く試すものだからです。バージョン情報を隠しても、脆弱なプラグインが入っていれば狙われます。ログインURLの変更も、ボットによるログイン試行を減らす程度で、弱いパスワードや更新漏れの代わりにはなりません。
やるなら、10項目に取り組んだうえでの、おまけとして考えましょう。
まとめ
セキュリティ対策は、一度やれば終わりではありません。新しい脆弱性は毎週のように見つかります。
まず取り組みたい順番は、次のとおりです。
- 更新:サーバー、PHP、WordPress本体、プラグイン、テーマ
- 認証:長いパスワード、使い回さない、2段階認証、ログイン試行の制限
- 実装:出力時のエスケープ、トークンと権限チェック、プレースホルダ
- 備え:WAF、バックアップと復元テスト、ログ
自社だけで全部を見るのが難しいときは、外部の診断や保守を頼るのも手です。不安なことがあれば、お気軽にご相談ください。
参考
- パスワードの新常識(NIST SP 800-63B-4)|PC-Webzine
- 安全なウェブサイトの作り方|IPA
- 安全なウェブサイトの作り方 改訂第7版(PDF)|IPA
- Hardening WordPress|WordPress Developer Resources
- Nonces|WordPress Developer Resources
- State of WordPress Security in 2026|Patchstack
- Patchstack’s 2026 WordPress Security Report|The Repository
- 結局、パスワードの定期的な変更は必要なのか?|トレンドマイクロ