← Reference

Debug mode in production is the worst single setting

A debug error page shows your source, your config, and often your environment variables.

01

What it is

Every web framework has a development error page: the traceback, the source around the failure, the local variables, the loaded settings. It exists to make debugging fast and it is excellent at that.

Left on in production, the same page renders for strangers. Django prints your settings. Laravel's Whoops shows your source and .env values. The Werkzeug debugger in Flask goes further and offers an interactive Python console, which is remote code execution with a friendly interface.

02

How to fix it

One setting per framework. Django: DEBUG = False, and set ALLOWED_HOSTS or it will refuse to start. Laravel: APP_DEBUG=false and APP_ENV=production. Flask: never pass debug=True, and do not use the built-in server in production. Symfony: APP_ENV=prod, then clear the cache. Rails: config.consider_all_requests_local = false.

Then add real 404 and 500 pages, and send errors to a logging service so you still find out about them.

03

How to confirm the fix

Request a path that definitely does not exist on your live site. You should get a plain error page with no framework name, no version, and no file paths.

04

The mistake people make

Turning debug off and stopping there. If the page was live for any length of time, assume the environment variables it displayed are public — because search engines and scanners index these pages. Rotate every credential it could have shown.

Not sure whether this applies to you?

Give us the address and we will tell you. No code, no access, no install — and every finding we have is shown in full, including on the free trial.

Check a site