「ORMを使っているから大丈夫」という油断が招く罠：SQLインジェクションの本当の正体
こんにちは！セキュリティの世界へようこそ。
「ORM（Object-Relational Mapping）を使っているから、SQLインジェクションなんて関係ないよ」
もしあなたのチームでそんな会話が聞こえてきたら、少し立ち止まって一緒に中身を確認してみませんか？今日は、便利な道具であるORMの「裏側」に潜む落とし穴と、泥棒に入られないための賢い守り方について、身近な例えを交えてお話しします。
—
1. そもそもORMって何？家の鍵に例えてみよう
ORMとは、本来はエンジニアが「難しいSQL言語」を直接書かなくても、プログラミング言語（JavaやPython、Rubyなど）の書き方だけでデータベースを操作できるようにしてくれる「通訳」のような存在です。
これを、「家にある自動鍵開け機」だと想像してみてください。
普段は「玄関を開けて」とボタンを押せば、ORMという機械が正確に鍵を開けてくれますよね。これを使っている限り、あなたは複雑なピッキング技術を覚える必要はありません。これがORMの最大のメリットです。
しかし、もしあなたが「ちょっと変わった扉を開けたいから」と言って、機械をバイパスして自分で直接ハリガネ（生クエリ・Raw SQL）を突っ込んで鍵を開けようとしたらどうなるでしょうか？
そのハリガネが、泥棒にとっても「扉を開けるための道具」になってしまう。これが、ORMを使いながらSQLインジェクションを引き起こしてしまうメカニズムです。
—
2. 「生クエリ（Raw SQL）」という禁じ手
ORMは通常、入力されたデータを安全に処理する「防弾仕様のトンネル」を通します。ですが、複雑な集計や特殊な検索を行いたいとき、私たちはついつい「生クエリ（Raw SQL）」という機能を使って、直接データベースに命令を送りたくなります。
例えば、ユーザーIDで検索するコードを書いてみましょう。
【ダメな例：泥棒を招き入れるコード】
悪い例：ユーザーからの入力を直接文字列として埋め込んでいる
これだと、悪意のある攻撃者が「’ OR ‘1’=’1」などを入力すると、全データが漏洩します
user_input = request.GET[‘id’]
query = f”SELECT FROM users WHERE id = {user_input}”
db.execute(query) # 直接SQLを投げている
このコードの何が危ないのか？攻撃者はidの欄に「1 OR 1=1」という暗号を打ち込みます。すると、データベースは「IDが1の人を出す」のではなく、「すべてのデータを出せ」という命令だと勘違いして、扉を全開にしてしまうのです。
—
3. どうやって守ればいいの？「鍵の貸し借り」のルール
では、どうすれば安全に守れるのでしょうか。対策は非常にシンプルです。「自分でハリガネを使わず、最初から用意された『安全な穴』を通すこと」です。
【良い例：パラメータ化クエリ（プレースホルダ）】
多くのORMには、データを安全に埋め込むための「箱（プレースホルダ）」が用意されています。
良い例：ORMの機能を使って安全に値を渡す
user_input = request.GET[‘id’]
‘?’ の部分が安全な箱の役割を果たします
ORMが「これはただの文字データですよ」とデータベースに伝えてくれるため、
攻撃コードが混じっていても、単なる「文字列」としてしか認識されません
query = “SELECT FROM users WHERE id = ?”
db.execute(query, (user_input,))
ここでのポイントは、「命令（SQL）」と「データ（ユーザーの入力）」を完全に切り離しているという点です。泥棒がどんなに怪しい道具を持っていても、その道具が「ただの置物」として扱われるため、鍵はびくともしません。
—
4. 現場で守るべき「3つの心得」
最後に、新人エンジニアの方にぜひ覚えておいてほしい、現場での3つの鉄則をお伝えします。
1. 「生クエリ（Raw SQL）」は最後の手段にする
ORMの標準機能だけで解決できないか、まずは公式ドキュメントをもう一度読み返してみましょう。ほとんどの場合、ORMのメソッドで解決できます。
2. パラメータ化を徹底する
どうしても生クエリが必要な場合は、絶対に文字列結合（f"{id}"のような書き方）をしてはいけません。必ずそのフレームワークが推奨する「プレースホルダ機能」を使いましょう。
3. 「動的なクエリ」を疑う
「テーブル名」や「カラム名」などをユーザーの入力から動的に切り替える処理は、特に危険です。可能な限り、固定された選択肢の中から選ばせるように設計しましょう。
—
最後に：セキュリティは「完璧」ではなく「継続」
セキュリティ対策は、一度鍵をかけて終わりではありません。技術は常に進化し、攻撃手法も巧妙になっています。
でも、怖がる必要はありません。こうして「なぜ危ないのか？」という仕組みを理解し、一歩ずつ丁寧な実装を心がけるだけで、あなたの書くコードは格段に強固になります。
今日から、自分の書いたコードに「これは攻撃者に扉を開けさせる隙間がないかな？」と問いかけてみてください。その小さな習慣が、あなた自身と、あなたを頼るユーザーを守る最高の武器になりますよ！
それでは、また次回の記事でお会いしましょう。ハッピー・コーディング！
コメント