Laravel 12.x 本身不引入新SQL注入漏洞，但业务代码若沿用不安全写法风险仍存；修复需严守三原则：Raw方法必须绑定参数、动态标识符须白名单校验、原生查询禁用字符串拼接。
Laravel 12.x 本身不引入新SQL注入漏洞，但业务代码若沿用不安全写法，风险依然存在。修复核心是堵住三类高危点：Raw 方法未绑定参数、动态标识符（列名/表名/排序字段）未白名单校验、绕过 ORM 的原生查询直拼用户输入。
所有 Raw 方法必须配绑定数组
selectRaw()、whereRaw()、orderByRaw()、havingRaw()、groupByRaw() 这些方法只要含用户输入，就必须传第二个参数（绑定数组）。否则字符串直接进 SQL，等于裸奔。
- ❌ 错误：
$query->whereRaw("title LIKE '%$search%'")—— 单引号、UNION SELECT、延时盲注全可触发 - ✅ 正确：
$query->whereRaw("title LIKE ?", ["%{$search}%"])或$query->whereRaw("title LIKE concat('%', ?, '%')", [$search]) - ⚠️ 注意：不能写成
concat('%', '{$search}', '%')—— PHP 变量插值一出现，参数化就彻底失效
动态列名、表名、排序字段必须白名单硬校验
字段名等 SQL 标识符无法参数化（SQL 标准禁止），PDO 绑定只认“值”，不认“结构”。任何拼接都危险，哪怕只是 select("users_{$year}") 或 orderByRaw($sortField)。
- ✅ 推荐做法：定义允许值列表，严格比对
$allowedColumns = ['id', 'name', 'email', 'created_at'];<br>if (!in_array($request->input('sort'), $allowedColumns, true)) { abort(400); } - ✅ 更健壮方式：用映射表替代拼接
$columnMap = [2022 => 'sales_q1_2022', 2023 => 'sales_q1_2023'];<br>$col = $columnMap[$year] ?? abort(400);<br>$query->select($col);
- ❌ 禁止：
DB::raw("SELECT * FROM {$table}")、select("product_variant_{$id}")、orderByRaw($field . ' ' . $dir)（未校验）
禁用原生查询字符串拼接，改用构造器或绑定
DB::select()、DB::statement()、DB::update() 等原生执行方法完全跳过 Laravel 绑定机制，是最常被忽略的注入口。
- ❌ 危险写法：
DB::select("SELECT * FROM users WHERE email = '$email'")—— 无论加不加 addslashes，都挡不住多字节或布尔盲注 - ✅ 安全替代：
→ 改用查询构造器：DB::table('users')->where('email', $email)->get()
→ 必须用原生时，强制绑定：DB::select("SELECT * FROM users WHERE email = ?", [$email]) - ✅ 补充防护：在中间件或基类中全局拦截含
$request->input()直接拼入 SQL 字符串的模式，配合静态分析工具（如 Psalm + larastan）扫描关键词DB::.*\(|selectRaw|whereRaw|orderByRaw
不复杂但容易忽略：Laravel 的安全不是框架自动兜底，而是靠开发者守住“Raw 方法必绑定”“标识符必白名单”“原生查询必绑定”这三条线。Laravel 12.x 的底层机制没变，加固逻辑也完全适用。
