If APP_DEBUG is true in a Laravel production environment, error pages can show detailed information to anyone who triggers an error. The Laravel docs say production must always be false, because debug output risks exposing sensitive configuration values to your users.
What the setting controls
The debug option in config/app.php decides how much error detail is shown to the user. By default it reads the APP_DEBUG variable from your .env file. The framework default in the config file is false, so a true value in production usually means someone set it, often while chasing a bug and forgetting to switch it back.
Debug pages tend to include stack traces, file paths, query details and environment information. Those are exactly what an attacker wants when mapping an application. The documentation is explicit about the risk, so this is not a matter of taste.
How to check
Do not test by breaking production. Use safer routes:
- Read the effective value on the server, for example in
php artisan tinkerwithconfig('app.debug'). - Check the environment variables of your hosting platform, since real environment variables override
.env. - Compare staging and production settings in a single table.
- If you cache config, remember cached values stay until you rebuild the cache.
| Check | Command or place | Expected in production |
|---|---|---|
| Debug flag | config('app.debug') in tinker | false |
| Environment name | APP_ENV | production |
| Cached config | php artisan optimize after deploy | Rebuilt from current env |
| Error pages | Trigger a 404 in a safe path | Generic page, no trace |
The deployment docs also advise running php artisan optimize as part of deploys so configuration, events, routes and views are cached. Cached config means an edit to .env does nothing until you rebuild, which is a common reason a fix appears not to work.
How to keep it off
Set the value in the platform environment, not by editing files on the server. Add a deploy check that fails if APP_DEBUG is true when APP_ENV is production. Many teams add one line to their CI release job that reads the value from the target environment. Review any change to this variable in the same way you would review a change to a firewall rule.
Also check that your logs and error tracker are not a second route to the same details. Sending traces to a private tracker is fine. Showing them in the browser is not.
If you find it on
- Switch it to false and rebuild the config cache.
- Assume values shown on error pages could have been seen. Decide which secrets to rotate, starting with anything printed in environment dumps.
- Check access logs for odd requests that cause errors.
- Add the automated check so it cannot recur.
Quick check
Is APP_DEBUG false by default?
In the config file the default is false, and in production it should stay false. A fresh local install usually sets it to true in .env for development.
Does hiding errors hide bugs?
No. Log errors privately and review them. Users just see a generic page.
Safeguard's policy gates can enforce release checks like this one in your pipeline. A free scan is at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
