Laravel应用安全是验证、授权、配置、传输、日志五环节环环相扣的防御链；任一环节松动即可能被绕过。请求验证必须显式实现authorize()方法，Sanctum stateful域名须精确匹配前端完整协议+域名+端口，.env文件泄露会导致数据库密码、APP_KEY等全部暴露，权限变更后需手动执行php artisan permission:cache-reset刷新缓存。
直接说结论：Laravel 应用安全不是靠某个“开关”或“插件”一劳永逸，而是由验证、授权、配置、传输、日志这五个环节环环相扣构成的防御链；任何一个环节松动，都可能让攻击者绕过其他层。
请求验证不写 authorize() 就等于裸奔
生成的表单请求类（如 StoreUserRequest）默认 authorize() 返回 true，这意味着任何登录用户（甚至未登录）都能提交数据——哪怕你后面写了 @can 或中间件，也挡不住恶意 POST 请求直接打到控制器。
- 必须显式判断权限，例如：
return $user->can('create', User::class); - 不要依赖前端隐藏按钮或 JS 校验，
authorize()是服务端强制关卡 - 对批量操作（如
/users/batch-delete）要额外校验每个 ID 是否属于当前用户，不能只查一次权限
Sanctum 的 stateful 域配错会导致 CSRF 失效
如果你用 Sanctum 做 SPA 认证，但 config/sanctum.php 里的 stateful 数组没包含你的前端域名（比如漏了 https://app.example.com），那么 auth:sanctum 中间件会静默失败，用户看似登录成功，实际后续所有请求都被当成未认证处理。
- 开发环境加
localhost和127.0.0.1，但生产环境必须精确匹配前端完整协议+域名+端口（https://admin.myapp.io:8080） - 如果前端走反向代理（如 Nginx），确保
X-Forwarded-Proto和X-Forwarded-Host被正确传递，否则 Laravel 会误判来源域 - 检查响应头是否含
Set-Cookie: laravel_session=...，没有说明 stateful 配置未生效
.env 文件泄露比密码明文更危险
一个被 Git 提交的 .env 文件，等于把数据库密码、APP_KEY、FIREBASE_CREDENTIALS 全部送给攻击者——后者可直接读写 Firebase 存储桶，前者能解密所有已加密的用户数据（如 EncryptedString 字段）。
- 确认
.gitignore包含.env，且执行过git rm --cached .env（仅删除追踪，不删本地文件） -
APP_KEY泄露后，立刻重置：改密钥 + 清空所有cache和session表 + 通知用户重新登录 - 敏感路径（如
FIREBASE_CREDENTIALS=/var/secrets/firebase.json）的 JSON 文件权限必须是600，且属主为 Web 进程用户（如www-data）
最常被忽略的其实是「权限缓存未刷新」：用 spatie/laravel-permission 分配新权限后，如果不执行 php artisan permission:cache-reset，用户下次请求仍沿用旧缓存，导致授权逻辑失效——而这个命令不会自动触发，也不会报错。
