Is debug mode ever safe to leave on?

Only on a copy of the site nobody outside your team can reach, such as a local install or a password-protected staging environment. It is never safe on the version the public can request.

What's the difference between debug mode and PHP's own error reporting?

They're related but not the same setting. Joomla's $debug property controls Joomla's own error, deprecation and query output. Server-level PHP error display is a separate setting, and both should be off on a live site.

Debug Mode Left On In Production

How common is this?

1% of the Joomla sites we have this data for fail this check. Platform: Joomla.

Measured across the sites we audit, on each site's most recent snapshot.

What this check and mySites.guru tool looks at on your site

This check reads your site’s configuration.php file, the Joomla Global Configuration file, and checks the value of the $debug property. If it’s set to 1, debug mode is switched on for everyone who visits the site, not just for you.

The setting has one job: it tells Joomla whether to render its debug console at the bottom of every page. When it’s on, that console shows up for every request the site handles, admin or front end, logged in or anonymous, because the property is a global site setting rather than something scoped to your own session.

What debug mode hands an attacker for free

With debug mode enabled, Joomla prints its internal workings straight onto the page: every error, every deprecation notice, every SQL query it runs, and full stack traces when something goes wrong. That output includes real file paths on the server, the database table prefix, a list of every included file for the request, and, when an extension misbehaves, a trace that points directly at the file and line responsible. None of this is hidden behind a login, the same failure mode WordPress sites hit through their own debug settings, where WP_DEBUG_LOG writes errors to a file search engines go on to index. Anyone who loads the page, or deliberately triggers an error to see what comes back, gets it, with no need to authenticate first.

For someone probing the site, that’s reconnaissance handed to them for free. Working out which extensions are installed, and which versions, normally takes scanning and guesswork, or logging in somewhere the version number happens to be visible. With debug mode on, the included-files list and the SQL query log between them usually give away exactly that, in a single request, with no login required. A version number is only useful to an attacker as a lookup key against a public list of known vulnerabilities, and debug mode is what hands them that key.

A page that fails silently is more secure than one that fails loudly

Debug mode doesn’t cause errors. It decides who gets to see them when they inevitably happen anyway. On a live site the answer should always be nobody but you.

Debug mode exists so that a developer working on a local or staging copy can see what’s going wrong while they’re actively fixing it. It was never meant to run on the copy the public can reach, and turning it off doesn’t fix whatever bug triggered the errors in the first place, it just stops broadcasting the detail of that bug to every visitor while you fix it properly somewhere else.

The ordinary way this ends up switched on in production isn’t carelessness so much as a decision that never got reversed. An extension throws an unexplained error, someone enables debug mode to see the full trace and work out what’s wrong, finds the answer, fixes the extension, and moves on to the next task without ever going back to turn debug mode off again. It did exactly the job it was meant to do, once, and then kept doing something else entirely for however long it stayed on afterwards.

Worked through end to end: an attacker (or, just as often, an automated scanner working through a list of sites) requests a URL designed to throw an error, a malformed parameter, a path that doesn’t exist, or a request to an endpoint that expects data it wasn’t given. On a site with debug mode off, that gets a generic error page and nothing more. On a site with debug mode on, the response includes the full stack trace: which file threw the error, which extension it belongs to, and often the exact SQL query that was running at the time, prefix and all. None of that required a login, a vulnerability in the site, or any particular skill, just a request built to fail on purpose.

Debug System set to No

Debug System is set to No in Global Configuration on the live site. When something genuinely needs debugging, it happens on a local or staging copy nobody outside your team can reach, not on production with the output visible to every visitor. There’s no functionality lost by turning it off: visitors still see the same pages and the same working features, the only difference is what they see when something goes wrong, a plain error rather than a breakdown of exactly why.

How to fix it

Login to the Joomla administration, e.g. https://yoursite.com/administrator.
Go to System, then Global Configuration.
Open the System tab.
Under Debug Settings, set Debug System to No.
Click the Save button.

If you need to chase down a live issue and can’t reproduce it locally, don’t turn this on for the whole site. Reproduce it on a staging copy instead, or use a debugging approach that only reveals output to your own IP address or session, so the information reaches you and nobody else.

What mySites.guru does about it

mySites.guru checks every connected site for this setting and can turn debug mode off across every connected site with one click the moment it’s found switched on.