laravel自带安全机制扎实，但app_debug=true、db::raw()乱用、{!! $content !!}无过滤、@include($template)不校验、api路由误认csrf默认关闭是线上事故最高发的五处缺口。
直接说结论：Laravel 自带的安全机制很扎实，但APP_DEBUG=true、DB::raw()乱用、{!! $content !!}无过滤、@include($template)不校验、CSRF 在 API 路由中被误认为“默认关闭”——这五处是线上事故最高发的缺口。
DB::raw() 和 whereRaw() 怎么写才不会触发 SQL 注入
很多人以为用了 Query Builder 就绝对安全，结果在 whereRaw() 里拼接用户输入，等于亲手拆掉防护墙。
- 错误写法：
whereRaw("name = '" . $request->input('name') . "'")—— 单引号挡不住注入，攻击者输admin' OR '1'='1就穿透了 - 正确写法必须带占位符：
whereRaw('name = ? AND status = ?', [$name, $status]) -
DB::raw()本身不危险，危险的是把它当字符串拼接容器。例如DB::raw("'$request->input('order')'")是典型翻车现场 - DataTable 的排序字段（如
request()->get('order')）若直接进orderBy(DB::raw(...))，务必白名单校验：in_array($field, ['name', 'email', 'created_at'])
Blade 中 {!! $content !!} 和 @include($template) 的信任边界在哪
{{ $content }} 自动转义是默认保护层，但一旦你主动用 {!! $content !!} 或 @include($template)，Laravel 就完全交出控制权——它不判断内容是否可信，只负责执行。
PHP中文网提供Laravel 13.2.0版本下载，Laravel框架 是基于 PHP 8.3+ 的高性能框架，官方推荐通过 Composer 安装。它内置 AI SDK、JSON:API Resources 及原生向量搜索，支持属性驱动开发与队列路由，大幅提升开发效率。相比旧版，13.2.0 优化了缓存 TTL 管理与实时通信，无需 Redis 即可横向扩展。作为现代 Web 开发首选，它兼顾安全与极速体验，助您快速构建企业级应用。
-
{!! $content !!}只能用于**已净化过的富文本**：入库前用spatie/laravel-html-sanitizer或HtmlPurifier处理，不能依赖前端 JS 过滤 -
@include($template)若模板名来自请求参数（如@include(request()->input('view'))），可能加载任意 Blade 文件，导致模板注入 —— 必须白名单限制：in_array($view, ['mail/welcome', 'pdf/invoice']) - 邮件模板、PDF 渲染、API 响应中的 HTML 输出，同样受此规则约束；别以为“不在页面展示”就安全
API 路由为什么总被误认为“默认防 CSRF”
Laravel 的 api 中间件组确实没加载 VerifyCsrfToken，但这不是“已防护”，而是“裸奔”。很多后台接口走 API 路由却没加认证，等于把管理权限敞开。
- Web 表单必须用
@csrf，且不能从app/Http/Middleware/VerifyCsrfToken.php的$except里随意加路由 —— 白名单要最小化，比如只放stripe/webhook - SPA 后台（如 Inertia + Laravel）如果混用
web和api路由，注意X-XSRF-TOKENcookie 由web中间件维护，api路由拿不到 —— 别指望它自动生效 - 真正需要 CSRF 的 API 接口（比如内部管理系统的数据修改），应显式切回
web中间件：Route::post('/admin/update')->middleware('web')
.env 和 APP_KEY 泄露后会发生什么
这两个不是“配置项”，是系统密钥。泄露一个，整个应用加密体系就崩了：session 可被伪造、remember_token 可解密、加密 Cookie 可篡改、队列任务可反序列化执行任意代码。
-
.env绝对不能进 Git —— 检查.gitignore是否含.env，CI/CD 中禁用git log -p查敏感信息 -
APP_KEY一旦泄露，必须立刻轮换：生成新 key（php artisan key:generate），同时清空所有 session 表、重置用户 remember_token、作废所有加密 Cookie - 生产环境禁用
APP_DEBUG=true，否则 Ignition 错误页会暴露.env全量内容 —— CVE-2021-3129 就是靠这个链路打穿的
最常被忽略的其实是「信任传递」：一个地方做了净化，不代表下游所有使用点都安全。比如富文本入库前净化了，但导出 PDF 时又原样取出渲染，或缓存成 JSON 后被 API 直接返回——这些环节都要独立校验，不能默认“前面做过就万事大吉”。
