Displaying Safe Error Messages
When building PHP applications, it is critical to avoid exposing detailed error messages to users. Revealing internal system details—such as file paths, database queries, or stack traces—can provide malicious users with valuable information about your application's structure and potential vulnerabilities. Instead, you should display safe, generic error messages that inform the user something went wrong, without revealing sensitive information. At the same time, you still need to capture and store detailed error information internally for debugging and troubleshooting purposes.
error_handling_example.php
123456789101112131415161718192021222324<?php // error_handling_example.php // Set up error logging to a file ini_set('log_errors', 1); ini_set('error_log', __DIR__ . '/app_errors.log'); // Custom exception handler set_exception_handler(function ($exception) { // Log the detailed error message internally error_log("Exception: " . $exception->getMessage() . " in " . $exception->getFile() . " on line " . $exception->getLine()); // Display a generic message to the user echo "Sorry, something went wrong. Please try again later."; }); // Example function that throws an exception function riskyOperation() { throw new Exception("Database connection failed: Access denied for user 'admin'@'localhost'"); } // Attempt the risky operation riskyOperation(); ?>
In the example above, you see how to separate user-facing error messages from internal error details. The script sets up error logging so that all errors are written to a file. The custom exception handler logs the full exception message, including the file and line number, to the log file, which is only accessible to administrators. Meanwhile, users only see a generic message—"Sorry, something went wrong. Please try again later." This approach ensures users are not exposed to sensitive system information, while developers and administrators still have access to the technical details necessary for troubleshooting.
Дякуємо за ваш відгук!
Запитати АІ
Запитати АІ
Запитайте про що завгодно або спробуйте одне із запропонованих запитань, щоб почати наш чат
Чудово!
Completion показник покращився до 8.33Displaying Safe Error Messages
Свайпніть щоб показати меню
When building PHP applications, it is critical to avoid exposing detailed error messages to users. Revealing internal system details—such as file paths, database queries, or stack traces—can provide malicious users with valuable information about your application's structure and potential vulnerabilities. Instead, you should display safe, generic error messages that inform the user something went wrong, without revealing sensitive information. At the same time, you still need to capture and store detailed error information internally for debugging and troubleshooting purposes.
error_handling_example.php
123456789101112131415161718192021222324<?php // error_handling_example.php // Set up error logging to a file ini_set('log_errors', 1); ini_set('error_log', __DIR__ . '/app_errors.log'); // Custom exception handler set_exception_handler(function ($exception) { // Log the detailed error message internally error_log("Exception: " . $exception->getMessage() . " in " . $exception->getFile() . " on line " . $exception->getLine()); // Display a generic message to the user echo "Sorry, something went wrong. Please try again later."; }); // Example function that throws an exception function riskyOperation() { throw new Exception("Database connection failed: Access denied for user 'admin'@'localhost'"); } // Attempt the risky operation riskyOperation(); ?>
In the example above, you see how to separate user-facing error messages from internal error details. The script sets up error logging so that all errors are written to a file. The custom exception handler logs the full exception message, including the file and line number, to the log file, which is only accessible to administrators. Meanwhile, users only see a generic message—"Sorry, something went wrong. Please try again later." This approach ensures users are not exposed to sensitive system information, while developers and administrators still have access to the technical details necessary for troubleshooting.
Дякуємо за ваш відгук!
