← Back to Baseline

Why it Matters

If exceptions are not handled safely, Magento may display stack traces, file paths, SQL queries, or sensitive configuration details to customers. Attackers can use this leaked information to discover modules, database schema, and entry points for attacks.

On production, exceptions should be logged internally but shown as friendly error pages without sensitive details. This reduces information leakage while still giving admins access to the root cause in the logs.

Verification Steps

Browser check

# Trigger an error (e.g., invalid URL or module crash)
# Expected: customer sees a generic "Something went wrong" page
# NOT a detailed stack trace

Log inspection

# Check var/log/exception.log
# Expected: stack trace and details logged securely

Remediation / Fix Guidance

  1. Ensure Magento runs in production mode (see MB-R031). This automatically suppresses verbose error output.
  2. Verify that display_errors is off in PHP configuration (see MB-R033).
  3. Customize pub/errors/default/ to show user-friendly error pages instead of raw exception dumps.
  4. Ensure logs are written to var/log/ and protected from public access (see MB-R042).
  5. Monitor exception logs regularly for recurring issues.

Examples

Fail Example
# Browser shows raw stack trace
Exception: SQLSTATE[42S02]: Base table not found: 1146 Table 'magento.customer_entity' doesn't exist
# File paths and SQL exposed → FAIL
Pass Example
# Browser shows
"Something went wrong while processing your request."
# Details captured only in var/log/exception.log → PASS

References