値と構造を区別する

SQLの検索条件に入る値はパラメータとして渡せますが、テーブル名、列名、並べ替え方向などは、通常同じ方法では扱えません。これらはSQLの構造を決める部分です。入力値をバインドしたつもりでも、列名だけを別途文字列連結していれば、その箇所に危険が残る場合があります。

画面の選択をコード側の固定値に変換する

架空の商品一覧を例にすると、画面の「価格が安い順」という選択は、サーバー側で決めた価格列と昇順に対応付けられます。利用者が送った文字列をそのまま列名として採用する必要はありません。対応表にない指定はエラーにするか、設計した既定の並び順に戻します。このように、受け付ける構造を固定するのが許可リストの考え方です。

複雑な検索ほど境界が増える

検索条件が増えると、列名、集計方法、並べ替えなど複数の可変部分が生まれます。値の部分にはバインドを使い、構造の部分には固定した対応付けを使うという区別が必要です。任意のSQL構造を利用者に指定させる設計そのものを見直した方が、処理を追いやすい場合もあります。

ストアドプロシージャも自動的に安全にはならない

処理をデータベース側へ移した場合でも、その内部で入力を連結して動的SQLを作れば、問題は残ります。特殊文字の置換だけに依存すると、処理系や文脈の違いを扱う負担も増えます。OWASPの資料は、パラメータ化と許可リスト、必要に応じた設計の見直しを示しています。本記事は特定の侵入手順ではなく、安全なSQL生成の仕組みを説明しています。

OWASP SQL Injection Prevention Cheat Sheet

記事更新・資料確認日：2026年9月12日。事例・注意喚起の時点は本文に記載しています。