Laravel如何防止SQL注入_Laravel数据库安全机制【详解】

Lara vel默认防SQL注入，因where()等方法自动使用PDO预处理绑定参数；但whereRaw()、表名列名等需白名单校验或手动绑定。

免费影视、动漫、音乐、游戏、小说资源长期稳定更新！ 👉 点此立即查看 👈

其实，Lara vel的SQL注入防护机制，很大程度上是“开箱即用”的。关键在于，你是否在正确的地方使用了正确的方法。只要避免手动将用户输入拼接到SQL字符串里，框架底层的PDO预处理机制就会自动为你保驾护航。换句话说，安全不是额外添加的，而是正确使用where()、update()、insert()这些方法时的自然结果。

where()、find()、whereIn() 等标准方法天然安全

这些方法是开发者的首选，因为它们天生就内置了参数绑定。无论用户输入多么“狡猾”，比如"1 OR 1=1"或者"admin' -- "，传到数据库引擎里时，都只会被当作普通的字符串值来处理，而不会被解析为SQL指令。这背后的功臣，正是预处理语句中的?占位符。

• User::where('email', $request->email)->first() —— 放心用，绝对安全。
• DB::table('orders')->whereIn('id', $ids)->delete() —— 即便$ids是个数组，也完全没问题。
• User::where('name', 'like', "%{$search}%")->get() —— 即使是模糊查询，框架也帮你做好了绑定，无需自己操心加引号。

whereRaw() 和 selectRaw() 是唯一需要你动手的地方

这两个方法提供了强大的灵活性，但代价是绕过了框架的自动安全机制。一旦在这里混入了未经处理的用户输入，风险立刻显现。可以说，这里是安全防线上需要你亲自值守的关卡。

• 错误示范：whereRaw("email LIKE '%{$_GET['q']}%'") —— 单引号和百分号都会被直接当作SQL语法执行，门户大开。
• 正确做法一（问号占位）：whereRaw("email LIKE ?", ['%' . $q . '%'])
• 正确做法二（命名绑定）：whereRaw("email LIKE :pattern", ['pattern' => '%' . $q . '%'])
• 更推荐的做法：其实，大多数情况下直接用where('email', 'like', "%{$q}%")就够了，语义清晰，且彻底杜绝了风险。

表名、列名、排序字段不能参数化，必须白名单校验

这里有个关键概念需要厘清：PDO的占位符?只能绑定“值”，不能绑定“标识符”。因此，像select($column)、orderBy($field)、DB::table($table)这类操作中，变量必须经过严格的白名单校验。

• 危险案例：DB::table('products')->select("product_varient_{$variant_id}") —— 如果攻击者传入$variant_id = "1 FROM users --"，最终SQL就会变成SELECT product_varient_1 FROM users -- FROM products，完全偏离了预期。
• 安全准则：务必使用验证器限定范围，例如在验证规则中定义'variant_id' => 'required|in:1,2,3'，或者在运行时使用in_array($variant_id, [1,2,3], true)进行判断。
• 一个常见的误区：不要以为强制类型转换（如(int)$variant_id）就万事大吉。攻击者传入"1; DROP TABLE users; --"，转换后确实是1，但如果这个值被用于其他上下文（比如日志拼接、缓存键生成），仍然可能埋下隐患。

DB::select() / DB::update() 等原生查询必须手动绑定

当你直接使用这些原生查询方法时，就完全脱离了Query Builder的保护层。此时，参数绑定与否，完全取决于你的代码习惯。没有绑定，就等于让查询语句“裸奔”。

• 错误写法：DB::select("SELECT * FROM users WHERE id = " . $id)
• 正确写法：DB::select("SELECT * FROM users WHERE id = ?", [$id])
• 另一种选择：命名绑定同样适用，例如DB::update("UPDATE users SET status = :status WHERE id = :id", ['status' => 'active', 'id' => $id])
• 需要警惕的是：模型中的$fillable和$casts属性与防SQL注入是两回事。$casts能确保数据类型，但不能替代参数绑定；$fillable是防止批量赋值漏洞的，和SQL语句的构造安全无关。

最后，必须强调一个最容易被忽略的盲点：动态的列名、排序字段、表名这些“标识符”，根本不在参数绑定的保护范围之内。很多开发者以为在whereRaw()里绑定了值就高枕无忧，却可能在select($userControlledColumn)这样的地方翻车。所以，对于这类输入，实施严格的白名单校验不是可选项，而是必须遵守的硬性规定。