security

Error Display Versus Logging

Users need safe error responses. Developers need detailed internal evidence. Displaying stack traces, SQL, paths, environment values, or tokens to users can turn an ordinary failure into a data leak.

Core Controls

  • Disable detailed error display in production.
  • Log exceptions with a request or correlation ID.
  • Return a generic message and appropriate status code to the user.
  • Redact secrets and personal data from logs.
  • Monitor recurring failures and protect log access.

Separate Public And Internal Messages

PHP example
<?php

declare(strict_types=1);

function publicErrorResponse(Throwable $exception): array
{
    $correlationId = bin2hex(random_bytes(8));

    error_log($correlationId . ' ' . $exception::class . ': ' . $exception->getMessage());

    return [
        'status' => 500,
        'message' => 'Something went wrong. Reference: ' . $correlationId,
    ];
}

$response = publicErrorResponse(new RuntimeException('Database connection failed.'));

echo $response['status'] . ' ' . $response['message'] . PHP_EOL;

The user sees a safe message and a reference. Operators get a searchable identifier and internal context.

Redact Before Logging

Do not write passwords, bearer tokens, session IDs, full payment details, or unnecessary personal data to logs. Redaction belongs in central logging configuration where possible, not in one controller.

Protect access to logs and define retention rules. Logs are useful production data and can become a security liability when copied broadly or retained forever.

Keep Production Display Off

Production should report errors internally while keeping display_errors off. A framework error page that is useful locally can leak stack traces, SQL, environment values, and paths in production.

In Application Work

Logging is a security feature only when operators can use it safely. Excessive logs can leak data; missing logs can hide abuse and make incident response difficult.

What To Check

Before moving on, make sure you can separate public and internal errors, attach correlation IDs, redact sensitive values, protect log access, and keep detailed display disabled in production.

Practice

Practice: Plan A Safe Error Response

Requirements

  • Return a generic public message.
  • Create a correlation ID.
  • Log enough internal context for diagnosis.
  • Redact tokens, passwords, and unnecessary personal data.
Show solution

Review Points

  • Disable detailed error display in production.
  • Log exceptions with a request or correlation ID.
  • Return a generic message and appropriate status code to the user.
  • Redact secrets and personal data from logs.
  • Monitor recurring failures and protect log access.