How to Fix Exposed Laravel Ignition Error Pages

Laravel Ignition error pages are visible in production, leaking stack traces and environment details. Learn how to disable them.

Critical severity Application Security Updated 2026-03-01 Markdown

The Problem

Exposed Ignition error pages display detailed stack traces, source code snippets, environment variables, and request data to anyone who triggers an error on your site. Ignition is Laravel's default error page handler during development, and when it appears in production it provides attackers with file paths, database credentials, package versions, and application architecture details.

How to Fix

Disable debug mode in production

Ignition only shows detailed error pages when APP_DEBUG is true. Set in your production .env:

APP_DEBUG=false
APP_ENV=production

Then clear and rebuild the cache:

php artisan config:clear
php artisan config:cache

2
Remove Ignition from production if not needed
Move Ignition to dev-only dependencies:
```
composer remove spatie/laravel-ignition
composer require spatie/laravel-ignition --dev
```
When deploying with --no-dev flag, Ignition will not be installed:
```
composer install --no-dev --optimize-autoloader
```

Create custom error pages

Create Blade templates for common HTTP errors so users see branded pages:

resources/views/errors/404.blade.php:

<x-layouts.app>
    <div class="flex items-center justify-center min-h-screen">
        <div class="text-center">
            <h1 class="text-6xl font-bold text-gray-300">404</h1>
            <p class="text-xl text-gray-600 mt-4">Page not found</p>
            <a href="/" class="mt-6 inline-block text-blue-600 hover:underline">Go home</a>
        </div>
    </div>
</x-layouts.app>

Create similar pages for 500.blade.php and 503.blade.php.

Configure error reporting to an external service

Replace visible error pages with proper error tracking. Install Sentry or Flare:

composer require sentry/sentry-laravel
php artisan sentry:publish

Add to your .env:

SENTRY_LARAVEL_DSN=your-sentry-dsn

This captures all errors with full context without exposing details to users.

How to Verify

Trigger a 500 error on your production site by visiting a broken route or temporarily throwing an exception. You should see your custom error page or a generic server error, not the Ignition debug screen. Test with:

curl -s https://yourdomain.com/non-existent-route | grep -i "ignition\|whoops\|stack trace"

This should return no matches.

Prevention

Deploy with composer install --no-dev to exclude debug packages. Add APP_DEBUG=false verification to your deployment pipeline. Use StackShield to continuously verify that Ignition pages are not exposed after deployments or configuration changes.

Frequently Asked Questions

What is the difference between Ignition and Whoops?

Ignition replaced Whoops as Laravel's default error page handler starting in Laravel 6. Ignition provides more features like solution suggestions and a stack trace viewer. Both expose the same critical information (environment variables, source code, queries) when visible in production.

Can Ignition be exploited beyond just information disclosure?

Yes. Older versions of Ignition (before 2.5.2) had a remote code execution vulnerability (CVE-2021-43617) that allowed attackers to execute arbitrary code through the Ignition debug endpoint. Always keep Ignition updated and never expose it in production.

Related Guides

Critical

Is your Laravel app exposed right now?

34% of Laravel apps we scan have at least one critical issue. Most teams don't find out until something breaks. Our free scan checks your live application in under 60 seconds.

18% have debug mode on

72% missing security headers

12% have exposed .env

Scan My App Free No signup required. Results in 60 seconds.