Information Disclosure

Also Known As

TL;DR

Explanation

Information disclosure vulnerabilities range from verbose error messages that reveal database structure and file paths, to response headers advertising framework versions, to source code accessible via backup file extensions (.php.bak, .php~). Even small disclosures aid attackers in fingerprinting the stack. Mitigate by disabling display_errors in production, implementing a custom error handler, reviewing response headers with expose_php=Off, and auditing for accessible backup files.

Common Misconception

Why It Matters

Common Mistakes

• Displaying detailed PHP error messages (with file paths and line numbers) in production.
• Exposing X-Powered-By, Server, and X-Generator headers that reveal technology stack and versions.
• Leaving phpinfo() or test scripts accessible in the webroot.
• Stack traces in API error responses that reveal internal class names, file paths, and query structure.

Code Examples

// Stack trace exposed to the user
try {
    \$result = \$this->process(\$data);
} catch (\Throwable \$e) {
    return response()->json([
        'error' => \$e->getMessage(),
        'trace' => \$e->getTrace(), // reveals file paths, class names
    ], 500);
}

try {
    \$result = \$this->process(\$data);
} catch (\Throwable \$e) {
    \$this->logger->error('Process failed', [
        'exception' => \$e->getMessage(),
        'trace'     => \$e->getTraceAsString(),
    ]);
    // Generic message to the user — no internals leaked
    return response()->json(['error' => 'An internal error occurred.'], 500);
}

// php.ini:
// display_errors = Off
// expose_php     = Off  ← removes X-Powered-By: PHP/8.x header

References

• ↗ https://portswigger.net/web-security/information-disclosure
• ↗ https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/01-Information_Gathering

Tags

Related Terms