确认APP_DEBUG是否为false、检查数据库凭证是否明文硬编码、验证表单是否含@csrf、运行composer audit扫描依赖漏洞、检查Blade中是否误用{!! !!}输出。
想在上线前揪出Laravel项目里那些藏得深、爆得狠的安全漏洞，又不想被官方文档绕晕？这篇教程直接从真实生产环境的审计现场切入，不讲概念，只教你怎么用命令、工具和配置项一处处扫雷。
确认应用是否启用调试模式
第一步：打开 .env 文件，查找 APP_DEBUG 配置项。
第二步：如果值为 true，立即改为 false → 本地开发可开，但任何公网可访问的环境都必须关。开启状态下会泄露完整错误堆栈、环境变量甚至数据库连接串，攻击者能直接看到你的密钥和SQL语句。
第三步：执行 php artisan config:clear 清除配置缓存，否则修改不生效。
检查数据库凭证是否硬编码在配置中
方法一：搜索 config/database.php 中是否出现 'password' => 'xxx' 或 'host' => '127.0.0.1' 这类明文字段。
方法二：运行 grep -r "DB_PASSWORD=" .env → 确保数据库密码只存在于 .env，且未被提交到 Git（检查 .gitignore 是否包含 .env）。
【.env 文件一旦被 Web 服务器误配导致可直接下载，所有数据库凭据瞬间裸奔】
验证CSRF保护是否覆盖全部表单提交
第一步：打开任意含 POST/PUT/PATCH/DELETE 的 Blade 模板文件。
第二步：确认每个表单开头都有 @csrf 指令 → Laravel 5.6+ 默认启用全局中间件 VerifyCsrfToken，但若手动关闭或排除了路由，该指令就成摆设。
第三步：在浏览器开发者工具中查看渲染后的 HTML，确认存在类似 <input type="hidden" name="_token" value="xxx"> 的字段。没有它，表单提交会被 419 错误拦截。
扫描Composer依赖是否存在已知高危漏洞
方法一：运行 composer audit（Laravel 11+ 内置）→ 自动检测 vendor/ 下所有包的 CVE 记录。
方法二：使用第三方工具：php ./scripts/composer-audit.php（需提前下载脚本）→ 它比原生命令更早支持 PHP 8.3 和私有仓库扫描。
这一步操作起来很简单，直接把命令复制粘贴进终端回车就行，但别跳过——去年 Laravel 社区曝出的 monolog 反序列化漏洞就是靠它最先发现的。
测试用户输入是否被正确转义输出
① 打开一个展示用户提交内容的 Blade 页面，比如评论列表页。
② 在对应变量输出处检查是否用了双大括号：{{ $comment->content }} → 这会自动 HTML 转义；若误用三括号 {!! $comment->content !!}，XSS 攻击立刻生效。
③ 手动构造一条含 <script>alert(1)</script> 的评论提交，刷新页面看是否弹窗。弹了，说明有漏洞；没弹，但源码里显示为文字，说明转义生效。
