Information Disclosure
debt(d5/e3/b3/t7)
Closest to 'specialist tool catches it' (d5). The detection_hints list owasp-zap, lighthouse, and semgrep — all specialist tools. Common patterns like display_errors=On or phpinfo() accessible are detectable by these tools but won't be caught by a default linter or compiler; they require deliberate scanning with a DAST or SAST tool against a running or static codebase.
Closest to 'simple parameterised fix' (e3). The quick_fix is a targeted set of ini/config changes (display_errors=Off, expose_php=Off, log_errors=On) plus wrapping exceptions to return generic messages. This is slightly more than a single-line patch because it touches php.ini, exception handlers, and potentially HTTP header configuration, but it stays within one component or deployment config layer — no cross-cutting refactor required.
Closest to 'localised tax' (b3). The applies_to scope is web contexts, and the fixes (config flags, exception handlers, header removal) are localised to deployment configuration and error-handling layers. It doesn't impose a persistent productivity tax across many work streams, but it does require ongoing discipline to not regress (e.g. adding new API endpoints that leak stack traces), justifying a slight upward nudge to b3.
Closest to 'serious trap' (t7). The misconception field explicitly captures the canonical wrong belief: developers assume only passwords and PII constitute information disclosure, while stack traces, server version headers, and phpinfo() outputs are treated as harmless. This contradicts standard security thinking and is a widely held wrong assumption that can persist until a breach occurs — not catastrophic in the 't9 obvious way is always wrong' sense, but a serious belief that contradicts how security professionals frame the concept.
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