Error messages expose internal details

SeverityMedium

ScopeWhole site

EffortSmall

Verified bySecurity scan (weekly, or Re-scan)

Rule keysec_error_disclosure

Short answer

A page Glimana loaded shows a raw error such as Warning: ... in /home/account/public_html/wp-content/plugins/x/file.php on line 42, a stack trace or a framework debug page. Turn off on-screen errors on the live site, log them to a file outside the web root, and then fix the error itself. Visitors and search engines see this text too.

Why it matters

Error output gives attackers the server's directory layout, the hosting account name, plugin and file names, and sometimes database queries or configuration values. A framework debug page (Laravel with APP_DEBUG=true) can expose environment variables, including database passwords and API keys, to anyone who triggers an error. File paths also make other attacks, such as file inclusion, much easier to aim.

The text reaches visitors and Googlebot as well: it can break the layout, appear in search snippets, and usually means something on the page is not working.

How Glimana detects it

Glimana looks at the HTML of your home page and up to two other pages exactly as they are served; it does not try to provoke errors. It reports Medium when it finds a PHP error message with a file path and line number (Fatal error, Parse error, Warning, Notice or Deprecated), a PHP stack trace, Laravel's "Whoops, looks like something went wrong" page or an Illuminate\…Exception class name. The issue shows the address and a short excerpt.

How to fix it

Watch out

WordPress writes WP_DEBUG_LOG output to wp-content/debug.log by default, which anyone can download unless it is blocked; give the log a path outside the web root. In Laravel, if the configuration is cached, a change in .env has no effect until you run php artisan config:cache again.

Find the finding in Glimana. Open Security; this check is in the Information leaks group, with the evidence from the last scan under its title. The same problem is listed under Issues › Error messages expose internal details.
Apply the fix on your platform.

WordPressPHPLaravel

In wp-config.php, above the line That's all, stop editing: define('WP_DEBUG', false);. If you need logging on the live site, use instead define('WP_DEBUG', true);, define('WP_DEBUG_DISPLAY', false);, define('WP_DEBUG_LOG', '/home/account/logs/wp-errors.log'); and @ini_set('display_errors', '0');. If your host turns display_errors on at server level, apply the PHP setting too.

In php.ini, .user.ini or your hosting panel's PHP options: display_errors = Off, display_startup_errors = Off, log_errors = On and error_log = /home/account/logs/php-errors.log (a folder outside the web root). Restart PHP-FPM, or wait for .user.ini to be re-read (every 5 minutes by default).

In .env on the live server: APP_ENV=production and APP_DEBUG=false, then php artisan config:cache. Errors are still written to storage/logs/. Do not leave debugging tools such as a debug bar enabled on production without access control.
Check it in Glimana. Press Re-scan on the Security page (up to two scans an hour) or wait for the weekly scan on Sunday; the problem closes when the check passes.

How the fix is verified

After fixing, press Re-scan on the Security page (or wait for the weekly Sunday scan); the problem closes as soon as the check passes.