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.
¡Gracias por tus comentarios!
Pregunte a AI
Pregunte a AI
Pregunte lo que quiera o pruebe una de las preguntas sugeridas para comenzar nuestra charla
Genial!
Completion tasa mejorada a 8.33Displaying Safe Error Messages
Desliza para mostrar el menú
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.
¡Gracias por tus comentarios!
