SQLインジェクション対策を「担当者の腕」に任せない制作会社へ──プレースホルダを社内標準にし、レビューで確かめ、顧客に説明できる品質に変える

この記事は、SQLインジェクション対策を、制作会社の「社内標準」と「品質の説明」に変える方法を扱います。

「うちのエンジニアはちゃんとやっている」は、品質の説明にならない

「SQLインジェクション対策は、大丈夫ですよね？」

顧客や情報システム部門から、こう聞かれる場面が増えています。
多くの社長は「担当がちゃんとやっています」と答えます。

けれど、その「ちゃんと」が、社内のどこにも書かれていないことがよくあります。
担当者が辞めれば消え、外注先には伝わらず、顧客には見せられません。

対策そのものより、対策が「会社の標準」になっていないことのほうが、経営のリスクです。

SQLインジェクション対策とは、データベースへの命令と、利用者が入力した値を「混ぜない作り方」を、会社として決めて守ることである

黒字化の外科医です。SQLインジェクション対策を、技術ではなく経営の標準として解剖します。

社内標準にすべき理由は、三つあります。

第一に、正しい作り方は、すでに公的な資料で決まっているから。
IPAの「安全なウェブサイトの作り方」（改訂第7版）は、根本的解決として「SQL文の組み立てはすべてプレースホルダで実装する」ことを挙げています。
php.netのPDOの説明も、プリペアドステートメントだけを使えばSQLインジェクションは起きないとしつつ、クエリの他の部分を未処理の入力で組み立てれば、なお起こり得ると注意しています。

第二に、事故の大きさに対して、対策の手間が小さいから。
OWASP Top 10（2025年版）は、SQLインジェクションを含む「Injection」をA05に挙げ、SQLインジェクションを「頻度は低いが影響は大きい」ものとして説明しています。
作り方を決めておけば、追加の工数はほとんどかかりません。

第三に、標準は、そのまま単価の根拠になるから。
「全案件でこの作り方を守り、納品前にこの手順で確かめています」と言える会社は、「安いところ」と同じ土俵で比べられにくくなります。

今すぐ試せる：自社の「SQLの書き方の標準」を下書きするプロンプト

私はWeb制作会社の経営者です。自社の「データベースを扱うコードの社内標準」を、A4で1枚に下書きしてください。

【前提】
・主に使う言語・フレームワーク・CMS：〔　　〕
・データベース：〔　　〕
・自作のコードを書く場面（独自の検索、会員機能、管理画面など）：〔　　〕
・外注先に開発を出すことがあるか：〔ある／ない〕

1. 「必ず守ること」を5項目以内で書く（プレースホルダの使用を中心に）。
2. 「やってはいけない書き方」を、攻撃の例は書かずに、書き方の特徴だけで示す。
3. 並び替えの項目名など、プレースホルダが使えない箇所の扱い（許可した値の一覧から選ぶ等）を書く。
4. 納品前のレビューで、誰が何を確認するかを書く。
5. 外注先に渡すときの一文を書く。

参考にする資料は、IPA「安全なウェブサイトの作り方」と、利用する言語の公式マニュアルに限ること。

SQL安全標準工場：社内ルール、レビュー、顧客への説明

社内標準の型（1枚に収める）

【データベース操作の社内標準】第〇版 〇年〇月〇日

1. SQLは、すべてプレースホルダ（プリペアドステートメント）で組み立てる
2. 文字列の連結でSQLを組み立てない
   （フレームワークの標準の仕組み・ORMを優先して使う）
3. 表名・列名・並び順など、値以外を外から受け取る場合は、
   許可した値の一覧から選ぶ形にする
4. データベースのエラーの内容を、画面にそのまま出さない
5. サイトが使うデータベースのアカウントには、必要な権限だけを与える

例外を作る場合：リーダーの承認と、理由の記録を残す

4と5は、IPAが「保険的対策」として挙げている項目です。万一のときの被害を小さくします。

納品前レビューの確認項目

□ SQLを組み立てている箇所を、一覧にしたか（検索・会員・管理画面・API）
□ 一覧のすべてで、プレースホルダまたはフレームワーク標準の仕組みを使っているか
□ 文字列の連結でSQLを作っている箇所が、残っていないか
□ 並び替え・絞り込みの項目名を、許可した値の一覧で受けているか
□ エラーの表示を、本番の設定で確認したか
□ データベースのアカウント権限を、確認したか
□ 外注先が書いた部分も、同じ基準で確認したか
□ レビューした人・日付・結果を、記録に残したか

レビューは、書いた本人以外が行います。「書いた人が確認した」は、確認の記録になりません。

顧客への説明文（例）

本サイトでデータベースを扱う機能（〔会員登録・検索など〕）は、
IPA「安全なウェブサイトの作り方」の根本的解決にあたる作り方
（プレースホルダによるSQLの組み立て）を、当社の社内標準として実装しています。
納品前に、開発者以外の担当者が該当箇所を確認し、記録を残しています。
なお、この説明は、すべての脆弱性がないことを保証するものではありません。

最後の一文は省かないでください。「絶対に安全」と書けば、品質の説明が、保証の約束に変わります。

責任の範囲を契約でどう決めるかは、こちらで整理しています。

▶ Web制作会社の責任と損害賠償は「サイトが攻撃された日」に問われる──制作と保守で違う責任の形、契約で決める上限・免責・範囲外・お客様の義務

構造的なリスク

逆説を指摘しておきます。

社内標準を作ると、「自作のコードは標準を守っている」ことで安心し、CMSのプラグインや外部のライブラリの中身を見なくなります。
自社が書いていない部分の脆弱性は、標準では防げません。

だから、標準には「自社が書くコード」と「選んで入れるもの」を分けて書きます。後者は、選定の基準と更新の管理で守ります。

▶ WordPress プラグイン 脆弱性の対応が追いつかない制作会社へ──入れる前の選定基準と、入れたあとの棚卸しで守る対象を減らす

よくあるQ&A

Q. WordPressだけで作っているので、関係ないのでは？

テーマやプラグインを自作・改修してデータベースを扱うなら、関係します。CMSが用意しているデータベース操作の仕組みを使うことを、標準に書いてください。

Q. 古いサイトの改修で、全部を直す予算がない。

まず、SQLを組み立てている箇所の一覧を作ります。そのうえで、外から値を受け取る箇所から優先して直す見積もりを出します。一覧そのものが、顧客への説明の材料になります。

Q. 脆弱性診断を受ければ、社内標準はいらないのでは？

診断は、できあがったものを確かめる工程です。作る段階の標準がなければ、診断のたびに同じ指摘で手戻りが出ます。診断の費用と発注のしかたは、別の記事で扱います。

▶ 脆弱性診断の費用は「範囲・画面数・手法」で決まる──相見積もりの金額だけで選ばないための発注のしかたと、比べ方の表

最後に

SQLインジェクション対策は、すでに正解が公的な資料で示されている、数少ない分野です。

正解を社内標準にし、レビューの記録を残し、顧客に説明できる形にした会社だけが、「ちゃんとやっています」を単価の根拠に変えられるのです。

続けて、画面への出力の安全設計も整えてください。

▶ XSS対策を「入力チェックをしているから大丈夫」で済ませていないか──出力時のエスケープを社内標準にし、CMS改修と外部タグまで含めて説明できる制作会社になる

これまでの記事は、メンバーシップ「黒字化オペ室」でまとめて読めます。月額1,980円、記事2本分の金額です。詳しくはプロフィールから。

#Web制作会社 #SQLインジェクション #セキュリティ #脆弱性対策 #社内標準 #コードレビュー #制作会社経営 #中小企業 #品質管理 #安全なウェブサイトの作り方