SQL注入、XSS、CSRF和敏感配置泄露是Laravel四大安全风险：须用参数绑定防SQL注入，富文本需入库前净化防XSS，Web表单必加@csrf且API慎用except放行，生产环境禁用调试并严格保护.env与APP_KEY。
SQL注入：别让 $request->input() 直接进 DB::select()
Laravel 的 Eloquent 和 Query Builder 默认使用预处理，但开发者手写原生查询时容易绕过防护。常见错误是拼接用户输入：DB::select("SELECT * FROM users WHERE name = '" . $request->input('name') . "'")——这等于把钥匙塞进攻击者手里。
正确做法只有一条：所有动态值必须用参数绑定。
- ✅ 用
DB::select("SELECT * FROM users WHERE name = ?", [$request->input('name')]) - ✅ Eloquent 中坚持用
where()链式调用，而非字符串拼接：User::where('email', $request->input('email'))->first() - ❌ 避免
DB::raw()包裹用户输入，比如DB::raw("'$request->input('sort')'")—— 单引号也挡不住注入 - ⚠️ 注意：即使用了
whereRaw()，也要配参数占位符：whereRaw('status = ? AND created_at > ?', ['active', $date])
XSS：Blade 的双大括号不是万能盾
{{ $content }} 确实会自动转义，但一旦你写了 {!! $content !!} 或用了 @verbatim，Laravel 就彻底放手。后台富文本、用户评论、第三方 API 返回的 HTML 内容，是最常翻车的地方。
关键判断点：这段内容是否“可信”？只要含用户可编辑字段，一律按不可信处理。
- ✅ 前端展示富文本前，用
strip_tags()或更严格的HtmlSanitizer（如spatie/laravel-html-sanitizer）过滤 - ✅ 后台存储时就做净化，而不是等到渲染才处理；否则缓存、API 输出、邮件模板全会中招
- ❌ 不要依赖前端 JS 过滤——攻击者绕过 JS 直接发请求
- ⚠️ 注意：Blade 中
@include()的文件名若来自请求参数（如@include($template)），可能触发模板注入，必须白名单校验
CSRF：表单没加 @csrf 不是“忘了”，是开了后门
Laravel 默认全局启用 CSRF 保护，但有两个典型漏网场景：API 路由和 SPA 接口。很多人误以为 “api 中间件组默认关了 CSRF”，其实只是没自动加载 VerifyCsrfToken——这不等于安全，而是等于裸奔。
- ✅ Web 路由（
routes/web.php）必须确保每个 POST/PUT/DELETE 表单都有@csrf，且不要手动删掉VerifyCsrfToken中间件 - ✅ API 场景下，如果确实需要 CSRF（比如管理后台的 API），显式加中间件：
Route::post('/user/update')->middleware('web')->uses(...) - ❌ 不要用
except列表放行敏感接口（如/api/user/delete），应改用 Token + 权限控制 - ⚠️ 注意：AJAX 请求若带
X-XSRF-TOKENheader，Laravel 会从 cookie 读取 token 校验；但 cookie 若没设HttpOnly和SameSite=Lax，仍可能被窃取
敏感配置泄露：别把 .env 提交到 Git，也别在异常页面暴露 APP_KEY
本地开发时抛出的异常页面（尤其是调试模式开启时）会显示完整环境变量，APP_KEY 一旦泄露，加密 Cookie、remember_token 全部可伪造。
- ✅ 生产环境务必设置
APP_DEBUG=false，且确认APP_ENV=production—— 两者缺一不可 - ✅
.env文件必须进.gitignore；检查历史提交：git log --oneline -p --grep="APP_KEY"，如有泄露立即轮换APP_KEY并重置所有用户 session - ✅ 使用
php artisan key:generate生成新密钥后，记得清空storage/framework/cache和storage/framework/sessions - ⚠️ 注意：自定义异常处理器若用了
config()打印配置，或日志里写了env('DB_PASSWORD')，也会导致泄露——永远别在日志/响应/错误页里输出敏感值
最麻烦的从来不是“该不该做”，而是“在哪做”——比如富文本过滤，得卡在入库前、API 输出前、邮件生成前三个节点；少一个，漏洞就藏进业务缝隙里了。
