SQLインジェクション — 入力からDBに不正な命令を送り込む

原因は一点です。入力を文字列連結で SQL に混ぜると、入力の中身が「命令の一部」として解釈されてしまう。

DB にとって届いた SQL は一続きの文字列です。命令の骨組みとデータの境目は、組み立てた側の意図でしかありません。連結でつなぐと、入力に混ぜた命令の切れ端が骨組みを書き換え、全件を抜く・消す・ログインを突破する、といったことが起きます。

登場人物メモ：

• ※1 命令とデータの分離 — SQL文の骨組みと、入力値を別々にDBへ渡す考え方
• ※2 最小権限 — アプリのDBユーザーに必要以上の権限を与えないこと

1. パラメータ化クエリ（プレースホルダ） — 命令の骨組みを先に固定し、入力は「値（データ）」として別枠で渡す。命令とデータが分離されるので入力は命令として動かない。これが王道
2. 文字列連結で SQL を組み立てない — これが鉄則。自前のエスケープは抜けやすい
3. ORMの適切な利用 — ORM も内部でパラメータ化を使うが、生SQLを組み立てる箇所は同じリスクなので油断しない
4. DBユーザーの最小権限 — アプリ用ユーザーに削除・全件取得などの過剰な権限を与えない。破られても被害を絞る
5. 識別子は許可リストで — 表名・列名・並び順（ORDER BY）はプレースホルダで「値」として渡せない。動的に変えるなら、固定の許可リストから選ぶ（入力をそのまま使わない）
6. エラー詳細を返さない — DBのエラーをそのまま画面に出すと、テーブル構造などのヒントを与える
7. 入力検証 — 補助として型や形式も確かめる

• エスケープ自作に頼る — 自前の文字置換は抜け穴が残りやすい。パラメータ化が正解
• エラーメッセージの露出 — 詳細を隠しても、応答の真偽や時間差から探るブラインドな手口がある。だからエラー非表示は補助
• ORMでも油断しない — 生SQLや動的な条件組み立ての箇所は同じリスク
• 種類を知る — 結果に差が出るエラーベース、差が見えにくいブラインド（真偽・時間差）など手口は複数あるが、対策の根本は同じ