# 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.

**Severity:** critical | **Category:** Application Security

---

## The Issue

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.

## Steps to Fix

### 1. 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

### 3. 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.

### 4. 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.

## Verification

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.