Security Tip: Disable Debug Mode on World-accessible Apps
[Tip#59] It may seem obvious, you'd be surprised just how often I come across websites where debug mode is enabled!
One of the first (and most important!) things you should do when deploying code into a world-accessible location is to disable debug mode. It’s something I discover all the time on random websites, and I’ve often heard arguments that it’s useful for debugging, but none of that outweighs the massive security risk of having debug mode enabled. So make it the first thing you do when deploying your code!
In Laravel, this is as simple as setting the APP_DEBUG
environment variable to false
within your .env
file:
APP_DEBUG=false
Setting APP_DEBUG
to false
disables the fancy error page that displays a significant amount of sensitive information about your app. This error page, and the information it contains, can leak all sorts of information, and is a gold mine for anyone trying to hack into your app or steal your user’s data.
Error messages themselves can also leak information - such as the full SQL query, or file paths, both of which are incredibly useful when trying to exploit a vulnerability, such as SQL Injection (SQLi), or Local File Inclusion (LFI).
While you’re at it, don’t forget to update APP_ENV
to production
, to instruct the app that it’s world-accessible and disable any other debugging features.
APP_ENV=production
My Recommendation
I recommend you update your .env.example
to have APP_DEBUG=false
and APP_ENV=production
set by default. This does mean you need to modify it any time you’re setting up a local dev, but it prevents you from deploying your code online, copying .env.example → .env
, and forgetting to disable debug mode.
Trust me, a little pain in local dev is worth it to prevent a breach in production!
As an example, here’s the top of my .env.example
for my Practical Laravel Security course:
APP_NAME="Practical Laravel Security"
APP_ENV=production
APP_KEY=
APP_DEBUG=false
APP_URL=https://practicallaravelsecurity.app
If you'd like to dig further into my recommendations for deploying apps check out:
What do I mean by “world-accessible”?
If the app can be accessed by anyone on the internet, then it’s world-accessible.
This doesn’t just mean production, but also staging, testing, and QA sites too. If a random person can discover the URL somehow and visit it, then it’s world-accessible.
If someone can break into your staging site - which is likely to be buggy and may have security vulnerabilities due to active development - they can then use this to pivot into your production site, or directly attack your developers. Having debug mode on these sites makes it even easier to compromise them, and in turn, makes it easier to attack production too.
As a side note, I recommend keeping staging, testing, QA, etc, sites on separate root domains and locked behind firewalls or Basic Auth. This makes them harder to find, less exploitable, and if auth is required before any code is touched, any weaknesses in dev code can’t be easily exploited.