网站报错页面自定义处理避免堆栈信息泄露

网站报错页面如果不加处理，直接抛出服务器默认的404、500或程序异常页面，往往会在页面上暴露服务器类型、框架版本、数据库错误详情甚至部分代码片段。攻击者利用这些堆栈信息可以快速定位漏洞，发起精准打击。解决这个问题的核心思路只有一条：拦截所有未处理的异常，重写错误响应，给用户展示友好页面，同时在服务端保留完整日志供开发人员排查。

堆栈信息泄露不是理论上的风险，而是每天都在发生的探测行为。攻击者通过故意构造异常请求，观察返回的详细报错页面，可以轻松获取后端语言版本、框架名称、中间件类型、数据库连接方式、内部文件路径等关键信息。有了这些信息，攻击者就能在漏洞库中匹配已知漏洞，或者直接推断出系统的薄弱环节。更严重的是，如果数据库连接字符串、密钥、Token等敏感配置在堆栈中被带出，攻击者可以直接获得系统权限。因此，自定义错误页面绝不是简单的美化工作，而是安全防御的第一道闸门。

一个成熟的错误处理机制应该分为三层。第一层是应用层拦截，在代码中捕获所有可能的异常，根据异常类型决定返回什么内容。第二层是Web服务器层兜底，当应用层没有处理到的异常穿透到服务器时，由服务器配置统一返回静态错误页面，不暴露任何后端信息。第三层是网关或反向代理层拦截，在流量入口处就过滤掉异常响应，确保无论后端发生什么情况，用户看到的始终是标准化的友好页面。三层防护缺一不可，任何一层出现疏漏都可能导致信息泄露。

在Nginx中，可以通过error_page指令为不同的HTTP状态码指定自定义页面。配置示例如下：

server {
    listen 80;
    server_name example.com;
    root /var/www/html;

    # 关闭在错误页面中显示Nginx版本号
    server_tokens off;

    # 为常见错误状态码指定自定义页面
    error_page 400 /errors/400.html;
    error_page 401 /errors/401.html;
    error_page 403 /errors/403.html;
    error_page 404 /errors/404.html;
    error_page 500 502 503 504 /errors/50x.html;

    # 确保错误页面路径可以被访问
    location = /errors/400.html {
        internal;
    }
    location = /errors/401.html {
        internal;
    }
    location = /errors/403.html {
        internal;
    }
    location = /errors/404.html {
        internal;
    }
    location = /errors/50x.html {
        internal;
    }
}

上面配置中internal指令很关键，它表示这些错误页面只允许内部重定向访问，用户无法直接在浏览器地址栏输入URL来访问这些页面，避免被恶意扫描利用。server_tokens off可以隐藏Nginx版本号，减少信息暴露面。错误页面本身应该是一个纯静态HTML文件，内容简洁友好，可以包含返回首页的链接或搜索框，但绝不能包含任何动态生成的内容。

Apache同样支持通过配置文件或.htaccess文件来设置自定义错误页面。在httpd.conf或虚拟主机配置中添加：

# 隐藏Apache版本信息
ServerSignature Off
ServerTokens Prod

# 自定义错误页面
ErrorDocument 400 /errors/400.html
ErrorDocument 401 /errors/401.html
ErrorDocument 403 /errors/403.html
ErrorDocument 404 /errors/404.html
ErrorDocument 500 /errors/500.html
ErrorDocument 502 /errors/502.html
ErrorDocument 503 /errors/503.html

ServerSignature Off指令关闭了错误页面底部的服务器签名，ServerTokens Prod则限制响应头中只显示Apache字样而不带版本号。ErrorDocument的路径是相对于网站根目录的，确保这些HTML文件真实存在且内容不包含任何服务器端变量。如果网站使用了反向代理，还需要在代理配置中确保错误页面能正确返回。

Web服务器层面的配置只能处理HTTP状态码类的错误，对于程序运行时的异常，必须在代码中做全局捕获。以PHP为例，可以注册全局异常和错误处理函数：

// 设置生产环境不显示错误
ini_set('display_errors', 0);
ini_set('display_startup_errors', 0);
error_reporting(E_ALL);

// 自定义错误处理
function customErrorHandler($errno, $errstr, $errfile, $errline) {
    // 记录详细错误日志
    error_log("Error [$errno]: $errstr in $errfile on line $errline");
    // 返回友好页面
    http_response_code(500);
    include $_SERVER['DOCUMENT_ROOT'] . '/errors/500.html';
    exit;
}

// 自定义异常处理
function customExceptionHandler($exception) {
    error_log("Exception: " . $exception->getMessage() . 
              " in " . $exception->getFile() . 
              " on line " . $exception->getLine());
    http_response_code(500);
    include $_SERVER['DOCUMENT_ROOT'] . '/errors/500.html';
    exit;
}

// 注册处理器
set_error_handler('customErrorHandler');
set_exception_handler('customExceptionHandler');

这段代码的核心思想是：用户永远只看到静态的500.html页面，而真实的错误详情被写入服务器日志文件，只有运维和开发人员才能查看。display_errors必须设为0，这是生产环境的基本要求。错误日志可以写入文件，也可以发送到集中式日志平台，方便后续分析和告警。

在Spring Boot应用中，使用@ControllerAdvice注解可以统一处理所有控制器抛出的异常。实现方式如下：

@ControllerAdvice
public class GlobalExceptionHandler {

    @ExceptionHandler(Exception.class)
    public ResponseEntity