生产环境中的详细错误页面和堆栈跟踪
当未处理的异常或针对不存在路由的探测在生产环境中触发框架的调试错误视图时，它可能会把你服务器的地图交给攻击者：文件路径、行号、库版本，有时甚至还有环境变量。修复方法是向用户返回通用的错误响应，同时只将完整细节记录到你的团队可控的服务器端服务中。
这是什么
每个 Web 框架都自带调试错误视图——Django 的黄色异常页面、Laravel 的 Ignition 界面、Next.js 的开发浮层、Express 的默认异常输出。它们在开发期间非常有用，但在生产构建中会被刻意禁用。风险在于：由于没有关闭调试模式而仍然处于活动状态的框架错误页面，或者直接在响应正文中返回原始异常对象的自定义错误处理程序。
AppSafe 通过请求一个你的网站上不应存在的路径来检测详细错误。如果响应正文匹配框架错误页面的常见模式——Python traceback、Node.js 异常输出、.NET 异常详情、Rails.root 路径等——该问题会以中等严重程度报告在「错误处理与容错」类别下。
为什么重要
堆栈跟踪会暴露语言和框架版本、应用的内部目录结构、出错的具体文件和行，以及导致错误的调用链。结合 CVE 数据库，这些信息会缩短从发现到实施针对性攻击的时间——尤其是针对特定框架或库版本中的已知漏洞。
调试页面还可能在渲染输出中包含请求数据、部分环境变量或 SQL 片段，无意中泄露用户输入或绝不应到达浏览器的服务器内部值。
如何修复
在 Next.js API 路由和 Route Handler 中，显式捕获异常，在服务器端记录完整错误，并向调用方返回通用状态。
// app/api/example/route.ts
export async function GET() {
try {
// ... handler logic ...
} catch (err) {
console.error(err); // logs stack trace to your server/monitoring only
return new Response("Internal Server Error", { status: 500 });
}
}Next.js 在生产环境中会为未处理的错误渲染 pages/500.tsx（App Router 中为 app/error.tsx）。在其中放置友好的提示信息——不包含任何技术细节——并接入 Sentry 等错误监控服务来捕获真实的异常。
对于任何逃逸出应用层的错误，nginx 可以在所有 5xx 响应到达浏览器之前将其替换为静态页面。
error_page 500 502 503 504 /50x.html;
location = /50x.html {
root /usr/share/nginx/html;
internal;
}常见问题
Next.js 在生产构建中会显示堆栈跟踪吗？
开发浮层在生产环境中已被禁用。真正的风险在于自定义的 Route Handler 或 API 路由捕获异常后将其直接序列化到响应中——框架本身不会阻止这种行为。
AppSafe 如何探测详细错误？
它会请求一个你的网站上不存在的 URL，并在响应正文中查找 'Traceback (most recent call last)'、'Stack trace:'、'Unhandled Runtime Error'、'Exception Details:' 等短语，以及来自 Python、Node.js、PHP、Java、Ruby 和 .NET 框架的类似标记。
我的 404 页面没有显示堆栈跟踪，但 AppSafe 仍然标记了它。为什么？
扫描器会匹配一组广泛的模式，其中一些会出现在部分或经过脱敏的错误响应中。检查你的 404 或 500 响应正文中是否出现了异常类名、内部文件路径或框架标识符——即使是在注释或隐藏元素中。