Fix Improper Error Handling in Laravel

Information disclosure via verbose stack traces is a primary reconnaissance vector. In Laravel, leaving APP_DEBUG=true in production exposes environment variables, database schemas, and internal logic flows to any unauthenticated attacker. A hardened application must intercept exceptions and return sanitized, generic responses while logging the raw payload internally for debugging.

The Vulnerable Pattern

// .env - CRITICAL RISK
APP_DEBUG=true
APP_ENV=production
// Controller logic leaking internal state
public function show($id) {
try {
return User::findOrFail($id);
} catch (\Exception $e) {
// Directly returning the exception message leaks DB structure
return response()->json([‘error’ => $e->getMessage()], 500);
}
}

The Secure Implementation

The fix involves two layers: environment hardening and exception abstraction. First, setting APP_DEBUG=false disables the Ignition/Whoops error page, preventing the leak of the .env file contents and stack traces. Second, we implement a global exception renderer that intercepts throwables. Instead of echoing the raw exception (which might contain SQL fragments or file paths), we return a generic message and a unique reference ID. This reference ID corresponds to a log entry in storage/logs/laravel.log, allowing developers to debug without exposing sensitive metadata to the client.

// .env - SECURE CONFIGURATION
APP_DEBUG=false
APP_ENV=production
// bootstrap/app.php (Laravel 11) or app/Exceptions/Handler.php
$withExceptions = function (Exceptions $exceptions) {
$exceptions->render(function (Throwable $e, Request $request) {
if ($request->is(‘api/*’)) {
return response()->json([
‘message’ => ‘Internal Server Error’,
‘ref’ => ‘ERR_’ . bin2hex(random_bytes(4))
], 500);
}
});
};
// Controller logic
public function show($id) {
// Let the global handler deal with the exception
return User::findOrFail($id);
}