SQLインジェクション入門：WordPressの検索フォームで何を確認する？

入力欄とデータベースの関係

検索窓や絞り込みの入力をSQL文へ直接つなぐと、想定しない命令として解釈されるおそれがあります。これをSQLインジェクションと呼び、条件によって情報の漏えいやデータ変更につながります。独自のサイト検索や申請管理も確認対象です。

利用者が検索語を入れる場所、受け取る処理、データベースへの問い合わせを一覧にします。テーマやプラグインのコードを読めない場合は、開発担当者に該当箇所と標準APIの利用状況を確認してもらいます。

OWASPは、利用者の入力をSQL文へ文字列連結する代わりに、パラメータ化された問い合わせを使う方法を推奨しています。WordPressでは標準APIで処理できるかを先に検討し、独自SQLが必要なときはwpdbの準備機能を適切に利用します。

入力欄から危険そうな文字を削るだけでは、命令文とデータの分離を保証できません。検索語の検証と、問い合わせの組み立てをそれぞれ点検します。修正方法はデータベース接続方法や利用APIに合わせて担当者が選びます。

例えば名前順と新着順を切り替える場合、列名や並び順まで自由入力を許さず、事前に決めた選択肢へ対応させます。値を渡すためのプレースホルダーにあらゆるSQLの構成要素を入れれば安全になるとは考えません。

ページ番号や件数は数値の型と範囲を確かめ、抽出量に上限を設けます。想定外の値が届いたときの既定動作も決めます。入力項目ごとに利用箇所を対応させると、見落としを発見しやすくなります。

許可された検証環境で、通常の検索、日本語、空欄、想定外の並べ替えを試します。利用者の実データを用いて破壊的な試験を行わないでください。エラー時にSQL文や接続情報が公開画面に表示されないことも確認します。

データベースの接続アカウントが必要以上の権限を持っていないかはサーバー担当者と確認します。修正箇所、テスト結果、公開日を残し、テーマやプラグインの更新時に独自修正が失われない構成にしましょう。

依頼文には、対象画面、入力項目、保存や検索の目的、想定される正常な結果を記載します。検索語だけでなく、カテゴリ、並び順、ページ番号などSQLの組み立てに影響する値をすべて挙げると、担当者が確認範囲を決めやすくなります。

修正の回答では「標準APIを使用」「入力値をパラメータとして渡す」「並び順を固定候補から選択」など、実際に採用した方式と検証結果を受け取ります。回答の有無だけで安全を保証せず、提供された変更と権限の確認を合わせて行いましょう。

データベースに直接問い合わせる独自コードが多い場合は、一つの入力画面だけで完了とせず、管理画面、検索結果、APIなどで同じ値を使う箇所も確認します。自サイトの処理で何を読んだり書いたりするかを明示してください。

確認日：2026-11-02。提供条件や仕様は変更される場合があります。