Laravel日志和异常页面泄露敏感GET参数，因Request对象默认在异常堆栈、日志及调试页中明文输出完整query string；需通过脱敏中间件覆盖敏感键为*、禁用APP_DEBUG并配置Web服务器访问日志过滤。
为什么 Laravel 日志和异常页面会泄露敏感 GET 参数
默认情况下，Laravel 的 Illuminate\Http\Request 会在异常堆栈、日志（如 storage/logs/laravel.log）甚至调试页面（APP_DEBUG=true 时）完整输出当前请求的全部 query string。如果 URL 包含 token、api_key、password、code 等参数，这些值会明文出现在日志文件或浏览器报错页里——哪怕你没主动打印 $request->query()。
如何全局屏蔽特定 GET 参数的记录与显示
Laravel 提供了 App\Exceptions\Handler 中的 report() 和 render() 钩子，但更直接有效的是利用框架内置的 Log::useContext() + 请求脱敏中间件，配合 config/logging.php 的 tap 配置。关键不是“过滤日志内容”，而是“让 Request 对象在序列化时自动隐藏敏感字段”。
- 在
app/Http/Middleware/StripSensitiveQueryParams.php中创建中间件：
public function handle($request, \Closure $next)
{
// 只影响日志和调试输出，不修改实际请求逻辑
$sensitiveKeys = ['token', 'api_key', 'password', 'secret', 'code', 'access_token'];
foreach ($sensitiveKeys as $key) {
if ($request->has($key)) {
// 强制覆盖 query 参数，使其在 __toString() / toArray() 中返回占位符
$request->merge([$key => '***']);
}
}
return $next($request);
}
- 注册到
$middlewareGroups['web']或$middleware（推荐放最前） - 注意：该方法仅影响
$request->query()和$request->__toString()行为，不影响路由匹配或控制器内$request->input($key)的原始值（因为input()读取原始 $_GET）
避免脱敏后丢失真实参数值的陷阱
上面的 $request->merge() 是临时覆盖，对后续业务逻辑无副作用，但如果你在中间件里调用过 $request->all() 或 $request->query()，它们返回的已经是脱敏后的数组。真正需要原始值的地方（比如鉴权验证），必须改用 $_GET 原生超全局变量或 $request->server->get('QUERY_STRING') 手动解析。
- 错误写法：
$token = $request->query('token');→ 返回*** - 正确写法：
$token = $_GET['token'] ?? null;或parse_str($request->server->get('QUERY_STRING'), $raw); $token = $raw['token'] ?? null; - 不要在中间件里做
$request->offsetSet()或修改$request->queryParameters属性——这些是私有属性，Laravel 10+ 已设为readonly
生产环境还需额外关掉调试信息暴露
即使做了请求脱敏，若 APP_DEBUG=true，Whoops 页面仍可能通过 “Request payload” 标签页显示原始 URL。这不是中间件能拦截的，必须靠配置兜底：
- 确保生产环境
.env中APP_DEBUG=false - 检查
config/app.php的debug值是否被硬编码覆盖 - 禁用 Whoops 的 query 显示（可选）：在
app/Exceptions/Handler.php的render()方法中，对Illuminate\Foundation\Exceptions\Handler的父类行为不做干预，仅靠APP_DEBUG=false就足够让错误页不展示请求详情
最易忽略的一点：Nginx/Apache 访问日志默认记录完整 URL，需单独配置 log_format 过滤 query string，这和 PHP 层脱敏无关，但同样会导致敏感参数落盘。
