DjangoのORMは「魔法」ではない：安全なクエリ構築とraw()の呪いを解く技術
現場でコードレビューをしていると、未だに「Djangoを使っているからSQLインジェクションは起きない」と信じ込んでいる若手が少なくない。確かにDjango ORMは、適切に使えばSQLインジェクションを根絶できる強力な武器だ。だが、武器を使いこなすのはあくまで人間だ。
今日は、多くの開発者が陥る「raw()メソッド」という名の落とし穴と、DjangoのORMが裏側で何をしているのか、その本質について深掘りしていく。
1. なぜORMは安全なのか？（魔法の正体）
Django ORMがSQLインジェクションに強い理由は、開発者が意識せずとも「クエリの構造」と「データ」を分離しているからだ。
安全な例
User.objects.filter(username=user_input)
このとき、Djangoは内部でSELECT ... FROM users WHERE username = %sのようなプレースホルダを用いたクエリを生成し、user_inputをパラメータとしてDBドライバに渡す。SQLのパーサーは、入力値が単なる「文字列」であることを理解しているため、どれだけ悪意あるSQLを流し込まれても、それはコマンドとして解釈されず、ただの「名前」として扱われる。これが「パラメータ化クエリ」の威力だ。
2. 禁断の果実：raw()メソッドの危険性
問題は、複雑な集計やレガシーなDB定義を扱う際に使われる Manager.raw() や connection.cursor().execute() だ。これらを使う際、以下のようなコードを書いていないか？
脆弱な実装（絶対にやるな）
危険：文字列フォーマットでSQLを連結している
user_id = request.GET.get(‘id’)
攻撃者が ‘1 OR 1=1’ を送ったらどうなるか想像してほしい
sql = f”SELECT FROM myapp_user WHERE id = {user_id}”
User.objects.raw(sql)
このコードは、攻撃者にDBの全権を渡しているのと同義だ。攻撃者は 1; DROP TABLE myapp_user; -- といった入力を送るだけで、テーブルを破壊できる。これがSQLインジェクションの古典にして究極の脅威だ。
3. 安全な実装パターン：パラメータ化の強制
raw() を使う場合、絶対に文字列連結をしてはいけない。Djangoはクエリの後に第二引数としてパラメータを渡す仕組みを用意している。
安全な実装例
安全：パラメータをタプルまたは辞書で渡す
user_id = request.GET.get(‘id’)
第2引数にparamsを指定することで、Djangoが自動的にエスケープを行う
query = “SELECT FROM myapp_user WHERE id = %s”
users = User.objects.raw(query, [user_id])
さらに高度なクエリが必要な場合、Django ORMの extra() は非推奨だ。代わりに、annotate() や ExpressionWrapper を使うのが現代的な開発の作法だ。これらはORMの抽象化レイヤー内で完結するため、安全性が担保される。
4. 現場で使える「防御の多層化」Tips
アプリケーションレイヤーで防ぐのは大前提だが、セキュリティのプロとして「万が一」を想定した多層防御も伝授しておく。
WAFによるSQLiシグネチャの遮断
AWS WAFなどを導入しているなら、SQLインジェクション攻撃によく使われるキーワード（UNION SELECT, OR 1=1など）を検知するマネージドルールを有効にしておくこと。
DBユーザー権限の最小化
これが意外と漏れている。Webアプリケーションが接続するDBユーザーに DROP TABLE や GRANT などの特権を与えていないか？
— 開発用DBではなく、本番環境のDBユーザー設定の例
— 必要なテーブルへのSELECT/INSERT/UPDATE権限のみを付与する
GRANT SELECT, INSERT, UPDATE ON myapp_user TO ‘web_user’@’localhost’;
REVOKE DROP, ALTER, TRUNCATE ON . FROM ‘web_user’@’localhost’;
最後に：エンジニアとしての矜持
「動けばいい」コードは、明日には負債になり、明後日には脆弱性になる。
DjangoのORMは非常に洗練されているが、それはSQLの知識を放棄していい理由にはならない。むしろ、ORMが裏でどのようなSQLを発行しているのかを connection.queries で確認する癖をつけてほしい。
「便利だから使う」のではなく、「安全であることを理解した上で使う」。
この一線こそが、三流のコーダーと一流のエンジニアを分かつ境界線だ。
君たちの書くコードが、誰かの資産を守る防壁になることを期待している。何かあればまた相談してくれ。
コメント