Laravel生产环境安全加固核心是三件事：密钥唯一、调试关闭、用户输入隔离。APP_KEY必须用php artisan key:generate生成且不进Git；APP_DEBUG=false且APP_ENV=production；SQL用占位符、XSS过滤富文本、CSRF加@csrf或middleware('web')；.env文件严禁Web访问。
生产环境的 Laravel 安全加固，核心就三件事：密钥必须唯一、调试必须关闭、用户输入必须隔离。其他所有措施——比如 CSP 头、权限白名单、富文本净化——都是在这三根支柱站稳之后才起作用的。
APP_KEY 为空或重复会导致加密失效
APP_KEY 不是“随便填个字符串就行”，它是 Cookie 加密、Session 签名、密码重置令牌等所有安全机制的根基。如果没生成、被硬编码成 base64:、或者多个实例共用同一个值，攻击者就能伪造会话、解密敏感数据、甚至接管账户。
- 必须运行
php artisan key:generate生成新密钥，并写入.env文件的APP_KEY=行，不能带引号、不能有空格 - 生成后立即执行
php artisan config:clear，否则缓存里还留着旧密钥 - 部署时若用 CI/CD，确保
.env不进 Git，且构建阶段不覆盖已有的APP_KEY - 多台服务器部署同一应用时，
APP_KEY必须完全一致，否则共享 Session 会失败
APP_DEBUG=false 不只是隐藏错误页面
设成 false 的本质是切断攻击者的信息获取链路。一旦开启，堆栈里会暴露绝对路径、数据库结构、环境变量、SQL 查询原文——这些足够拼出完整的攻击面。
- 检查
.env中APP_DEBUG=false后，还要确认APP_ENV=production，否则中间件组可能不生效 - 触发一个 404 或 500 错误，看返回页是否还有 “Whoops” 字样或文件路径；没有才真正关掉
-
storage/logs/目录需对 Web 用户可写，但绝不能被 Nginx/Apache 直接访问（Nginx 配置里加location /storage/logs { deny all; }）
用户输入进 SQL/XSS/CSRF 的三个关键拦截点
绝大多数漏洞不是框架没防护，而是开发者绕过了默认机制。重点盯住这三处：
- SQL 注入：只要用了
DB::select("SELECT * FROM users WHERE name = '" . $request->input('name') . "'")这类拼接，PDO 绑定就彻底失效；必须改用占位符DB::select("SELECT * FROM users WHERE name = ?", [$request->input('name')]) - XSS：Blade 的
{{ $content }}是安全的，但{!! $content !!}或@include($template)是高危操作；富文本入库前就得用spatie/laravel-html-sanitizer过滤，不能只靠前端展示时处理 - CSRF：Web 表单漏掉
@csrf是常见低级错误；API 路由默认不走VerifyCsrfToken，但如果接口在后台管理页调用（比如 AdminLTE 的按钮），就必须显式加->middleware('web')，否则等于裸奔
最容易被忽略的是：.env 文件权限和 Nginx 对它的保护。哪怕 APP_KEY 和 APP_DEBUG 都正确，如果攻击者能直接请求 /\.env 下载到文件，整个应用就等于交出去了——务必在 Web 服务器配置里封死所有对 .env 的访问。
