PHPの脆弱性対策｜セキュリティレベルの考え方と公開前の確認ポイント

「PHPは脆弱性が多いと聞くけれど、使っても大丈夫？」「サイトのセキュリティレベルを上げたいが、どこから確認すればよいのか」。PHPでWebアプリを作る人や、WordPressを運営する人にとって、気になる問題ではないでしょうか。

PHPのセキュリティは、言語名だけで判断できません。PHP本体の更新状況に加えて、アプリの作り方、利用するライブラリ、サーバー設定、公開後の運用を確認する必要があります。

この記事では、PHPで注意したい脆弱性と対策を整理し、セキュリティレベルの考え方、公開前の確認方法、WordPress運営者が取り組むことまで解説します。

更新情報の確認日：2026年10月22日。バージョンや修正情報は変わるため、対応時にはPHP公式と利用中のサービスの案内を確認してください。

１．PHPの脆弱性は「本体・部品・実装・設定」に分けて考える

脆弱性とは、攻撃に悪用される可能性がある弱点です。PHPを使ったサイトで問題が起きても、その原因がすべてPHP本体にあるとは限りません。

例えば、PHP本体に問題がある場合と、自作した検索機能でSQLを安全に組み立てていない場合では、必要な対策が異なります。まず、どの部分の問題なのかを分けて確認しましょう。

PHPを更新しても、自作コードの権限確認漏れまで自動的に直るわけではありません。反対に、コードを丁寧に書いていても、実行環境の重大な脆弱性を放置してよいことにはなりません。

２．最初に確認したいのは、サポートと修正の適用状況

PHPでは、バージョンの系列ごとにサポート期限が決まっています。利用中の系列がサポート対象かどうかと、その系列の必要な修正が適用されているかを、分けて確認してください。

「PHP 8系だから大丈夫」という判断では不十分です。同じ系列でも、修正前と修正後では対応状況が異なります。

2026年10月21日に公開された重大な脆弱性の修正

PHP公式は2026年10月21日、認証なしでのリモートコード実行につながる可能性がある２件の重大な脆弱性について、更新を呼びかけました。修正版として案内されたのは、PHP 8.5.12、8.4.27、8.3.36、8.2.35です。

この問題について、公式は完全な緩和策がないと説明しています。対象となる環境では、設定変更やWAFだけで対応を終えず、修正版の適用状況を優先して確認してください。

Linuxディストリビューションや保守サービスが、既存のパッケージに修正を取り込む場合もあります。表示されるバージョン番号だけで判断せず、提供元の案内で修正の有無を確認しましょう。

詳しくは、PHP公式のセキュリティ告知を参照してください。ここに記載した番号は当該問題の修正版であり、今後も安全を保証する固定の推奨バージョンではありません。

実際にWebサイトを動かしている環境を確認する

サーバーによっては、ターミナルで動かすPHPと、Webサイトを処理するPHPのバージョンや設定が異なります。レンタルサーバーの管理画面や運営会社への問い合わせで、対象サイトに適用されている環境を確認してください。

更新後は、必要な再起動や反映処理が完了しているかも確認します。ログイン、フォーム送信、ファイルアップロードなど、サイトの主要機能が動くことも確かめましょう。

３．PHPで注意したい主な脆弱性と対策

脆弱性への対策は、「危険そうな文字を削除する」という一つの処理では完結しません。入力をどこで使うのか、誰に何を許可するのかによって、必要な対策が変わります。

SQLインジェクション：SQLの構造と入力値を分ける

利用者の入力を文字列としてSQLへ直接つなげると、入力が命令の一部として解釈される危険があります。PDOを使う場合は、SQLをprepareで準備し、入力値をパラメーターとして渡す方法が基本です。

ただし、パラメーターで置き換えられるのは値です。テーブル名、列名、並び順などを自由に置き換えられるわけではありません。並べ替え機能では、選択可能な項目を開発者側で決め、その中から対応するSQLを選びます。

XSS：入力時だけでなく、表示する場所で対策する

入力をHTML本文に文字として表示する場合、PHPのhtmlspecialcharsが使えます。ただし、JavaScriptの中、URL、CSSなどへ埋め込む場合まで、同じ処理だけで対応できるわけではありません。

入力の形式を確かめる処理と、表示先に合わせてエスケープする処理は、役割が異なります。データベースから取り出した値も、保存済みだから安全だと考えず、出力する場所に合わせて扱ってください。

CSRFとアクセス制御：それぞれ別の確認が必要

CSRF対策は、利用者が意図しないリクエストを送らされる問題への対策です。一方、アクセス制御は、その利用者に対象の操作を許可してよいかを判断します。CSRFトークンを確認しただけで、権限確認が済むわけではありません。

例えば、会員が自分の住所を変更する機能では、ログイン状態だけでなく、変更対象がその会員の情報であることもサーバー側で確認します。画面から編集ボタンを隠すだけでは、操作の制限になりません。

更新・削除などの処理をGETリクエストだけで実行しない設計も重要です。ただし、POSTに変更するだけでCSRF対策が完了するわけではないため、フレームワークなどの保護機能を適切に使用してください。

４．パスワード・セッション・アップロードも確認する

パスワードは、保存と照合の仕組みを整える

パスワードを平文で保存したり、独自の変換方法で保護したつもりになったりしないようにします。PHPでは、password_hashによるハッシュの作成と、password_verifyによる照合が用意されています。

ハッシュ化は、元のパスワードへ戻すことを目的とした暗号化とは異なります。また、保存方法を整えるだけでは、ログインの総当たりや他サービスから流出した認証情報の悪用まで防げません。試行回数の制御や、多要素認証の導入なども検討します。

ログイン状態の保護は、Cookieの設定だけで終わらない

セッションCookieでは、HTTPSで送るためのSecure、JavaScriptからの読み取りを制限するHttpOnly、サイトをまたぐ送信を制御するSameSiteなどを確認します。SameSiteの設定は、外部サービスから戻るログイン処理などへの影響も検証してください。

加えて、ログイン成功時などのセッションID更新、利用期限、ログアウト時の失効を設計します。HttpOnlyを付けてもXSSそのものがなくなるわけではなく、SameSiteもあらゆるCSRF対策の代わりになるわけではありません。

アップロードされたファイルを、そのまま信用しない

ファイル名の末尾や、ブラウザから送られた種類の情報だけで安全性を判断しないようにします。必要な形式だけを許可し、内容やサイズを確認したうえで、保存名をアプリ側で生成します。

保存先はWebの公開領域から分離し、実行されない構成を検討します。非公開の書類であれば、ダウンロード時にも権限確認が必要です。アップロード時にログインを確認しただけでは、その後の公開範囲まで保護できません。

５．「セキュリティレベルが高い」とは、何を確認した状態なのか

PHPには、アプリ全体を一括して安全にする共通の「セキュリティレベル設定」があるわけではありません。サービスや教材に「高・中・低」の表示があっても、その意味は製品や機能ごとに確認する必要があります。

Webアプリの対策を整理する基準の一つに、OWASP ASVSがあります。認証、アクセス制御、入力の扱いなどについて、実装・検証すべき要件を確認するための標準です。

これは「診断ツールで問題が出なかったからレベル３」という判定ではありません。利用する標準の版、対象範囲、適用する要件、それを確かめた証拠をそろえる必要があります。

個人開発でも、「対策済み」とだけ記録するより、「どの機能で、何を確認したか」を残す方が役立ちます。未確認の項目を、問題なしとして扱わないことも大切です。

６．公開前は「できること」と「拒否されること」を試す

正常な利用者が操作できることに加えて、許可されていない操作が拒否されることを確認します。自分が管理する検証環境で、管理者・一般利用者・未ログインの状態を分けて試しましょう。

本番環境では、詳細なエラーを画面へ表示せず、管理者が確認できる場所に記録する構成にします。ただし、ログへパスワードやセッショントークンを残さないよう、記録する内容も選んでください。

Composerで管理するライブラリについては、composer auditで既知の脆弱性などを確認できます。ただし、この結果だけで自作コードの権限漏れや業務上の不正操作まで確認できるわけではありません。

AIによるコードレビューを使う場合

AIは、確認項目の整理や修正候補の検討に利用できます。ただし、「問題ありません」という回答を安全性の証明にはしないでください。指摘された内容はコードと公式資料で確認し、実際のテストにつなげます。

例えば、「利用者Aが利用者Bのデータを変更できないか」「この値はHTMLのどこへ出力されるか」のように、確認したい条件を具体的に伝えます。コードを共有する際は、認証情報や個人情報を除き、利用するAIサービスへの入力が許可されているかも確認しましょう。

７．WordPress運営者は、PHPとWordPress側の更新を分けて確認する

WordPressを利用している場合は、PHPの更新と、WordPress本体・テーマ・プラグインの更新を分けて管理します。WordPressの管理画面で更新が完了しても、サーバー側のPHPまで更新されたとは限りません。

まず、ホスティング会社がPHP本体の修正を提供・適用する範囲を確認してください。緊急の修正情報が出ている場合は、対象サイトへの適用状況を問い合わせることが具体的な一歩になります。

• PHP：サイトで使うバージョンと、修正の適用状況を確認する。
• WordPress本体・テーマ・プラグイン：更新情報を確認し、不要なものは依存関係を調べて削除する。
• アカウント：管理者を必要な人数に絞り、多要素認証などの保護を検討する。
• バックアップ：取得だけでなく、復元手順と保存先へのアクセス制限も確認する。
• 独自の改修：利用者の権限、入力、出力、変更処理の保護を確認する。

独自のプラグインやテーマを開発する場合、WordPressのnonceを確認するだけで権限確認が完了するわけではありません。公式資料でも、nonceを認証やアクセス制御の代わりに使わず、current_user_canなどで適切に確認するよう説明されています。

更新前のバックアップや動作確認は重要ですが、重大な脆弱性への対応を長期間先延ばしにしないようにします。問題が疑われる場合は、運営会社や保守担当者と連携し、対応範囲と手順を決めましょう。

８．公開後も、更新・監視・復旧を続ける

公開前に問題を見つけられなくても、その後に新しい脆弱性が判明することがあります。利用するPHP、ライブラリ、プラグインを把握し、誰が更新情報を確認するのかを決めておきましょう。

ログイン失敗の増加、意図しない管理者の追加、不審なファイル変更など、調査が必要になる出来事も整理します。ログを残すだけでなく、確認する担当者や通知先まで決めることが必要です。

不正アクセスが疑われる場合は、証拠となるログなどを保全し、影響範囲を調べながら、保守担当者とアクセス制限や認証情報の失効を進めます。更新しただけで、すでに行われた改ざんや情報流出まで解消したとは判断できません。

９．よくある質問

PHPを使うこと自体が危険なのでしょうか？

言語名だけで、サイト全体の安全性は判断できません。PHP本体の修正状況と、アプリの実装、利用する部品、サーバー設定を確認してください。他の言語に移しても、権限確認の不足などの問題が自動的になくなるわけではありません。

HTTPSにすれば、SQLインジェクションやXSSも防げますか？

HTTPSは、主に通信経路を保護する仕組みです。アプリ内部のSQLの組み立て方や、ブラウザへの出力方法の問題まで修正するものではありません。それぞれの処理に合った対策が必要です。

WAFやセキュリティプラグインがあれば十分ですか？

追加の防御として役立つ場合がありますが、更新や実装の修正に置き換えられるとは限りません。特に、利用者同士のデータの境界や業務固有の権限は、アプリ側で確認する必要があります。

初心者は、まず何から始めればよいですか？

最初に、公開中のサイトが使っているPHPと主要な部品、その修正状況を確認しましょう。自分で開発している場合は、ログイン、データの変更、ファイル公開など、影響の大きい機能から権限と入力・出力の扱いを点検してください。

10．まずは「何を確認できたか」を記録する

PHPのセキュリティ対策では、「最新にした」「ツールで診断した」という作業名だけで判断しないことが大切です。どの環境に修正が反映され、どの操作が許可・拒否されるかを確認しましょう。

まずは、利用環境、更新状況、重要な機能、確認結果を一つの表にまとめてみてください。未確認の項目に担当者と期限を付けることで、次に行う対策を具体化できます。

安全性を高める取り組みは、開発中の実装と公開後の運用につながっています。小さな確認を記録し、変更のたびに見直せる状態を作っていきましょう。

参考資料

• PHP：2026年10月21日のセキュリティ告知
• PHP：Supported Versions
• PHP：PDO::prepare
• PHP：htmlspecialchars
• PHP：password_hash
• PHP：password_verify
• PHP：セッションのセキュリティ設定
• PHP：エラー報告とセキュリティ
• OWASP：Application Security Verification Standard
• OWASP：XSS対策
• OWASP：CSRF対策
• OWASP：アクセス制御
• OWASP：ファイルアップロード対策
• Composer：audit
• WordPress：Nonces