DEBUG=TRUE: A Backend Security Scare in an Australian Election App

The Backstory

The Federal Election was just around the corner, and like many Australians, I was trying to stay informed. I was recommended what was described as a "civic engagement app", a tool designed to help users navigate the political landscape and potentially encourage participation.

I used the app, I enjoyed it, got the information I needed to be better informed for the election, and then started doing what I often do: peek behind the curtain using dev tools, ethically of course. I wasn't looking for vulnerabilities, just interested in the tech stack, how data was handled, maybe check out the API calls in the browser's developer console.

And that's when I found it. Not a complex zero-day exploit, but something much more fundamental, exposed through a common, yet critical, misconfiguration.

Browsing to what appeared to be a backend analytics endpoint (/api/analytics/dashboard/), I was greeted not with a login prompt or an error, but a raw JSON output revealing stats like "total_active_users_last_30_days": 585938.

Okay, that was interesting. It confirmed this app had significant reach – over half a million users in the lead-up to the election, but why is this endpoint visible to the public?

So I tried something, I removed the /analytics/dashboard/ from the URL, and yeah... the exposure didn't stop there. I tried one more trick, and just sent it a random query, and thats when I was served a stack trace, and blocks of sensitive configuration details.

DEBUG=True

The root cause of the exposure, as became clear quickly, was the classic "DEBUG=True" setting left enabled in a production environment's settings file.

In frameworks like Django, when DEBUG is set to True, verbose error pages are enabled, which often include detailed tracebacks and, critically, dump the entire application settings and environment variables onto the page whenever an unhandled exception occurs.

This simple setting, left on inadvertently, acted like an open door, revealing:

Leaked Backend JWT Auth Config: Details about their JSON Web Token setup, including the algorithm (HS256) and crucially, potentially hints about the SIGNING_KEY.

Leaked Backend Database Credentials: Yes, the database password. Including hostname, database name (postgres), and port. Having this exposed is incredibly risky, potentially granting an attacker direct access to user data, platform content, and operational logs.

Leaked AWS Creds & CORS Config: Details related to their Amazon Web Services setup, including potentially AWS Access Keys and Secret Keys. This could grant access to cloud storage (like S3), databases (RDS), or other critical cloud infrastructure.

All this information was just... there, sitting on a publicly accessible endpoint.

Misconfiguration is King (of Disasters)

This wasn't a sophisticated attack that required deep technical prowess.

It was a simple, yet catastrophic, misconfiguration. As we all known majority of data breaches don't come from cunning zero-day exploits or complex hacks, but from fundamental mistakes like leaving default credentials, failing to patch known vulnerabilities, or, in this case, flicking the wrong switch in the settings.

Leaving DEBUG=True in production is almost universally condemned in web development best practices precisely because of the risk of exposing this kind of sensitive information.

It's a development aid, not a deployment setting.

Swift Action, A Lucky Escape

Upon discovering this, my immediate priority shifted from curiosity to responsible disclosure.

Given the sensitivity of the data, the potential impact on half a million users, and the critical nature of election-related infrastructure, I contacted the development team immediately.

To their immense credit, they responded very quickly. We're talking minutes, not hours or days. They understood the gravity of the issue and had it resolved almost instantly, the platform even went offline for 1-2 hours whilst they resolved this issue and reset credentials everywhere as a saftey measure.

This level of responsiveness is exactly what you hope for when reporting a vulnerability, and they deserve praise for handling it professionally and rapidly.

However, the swift fix doesn't erase the initial exposure.

They were incredibly lucky that someone with good intentions found this and reported it ethically, rather than a malicious actor who could have potentially exploited this, and the potential for harm to both the platform and its large user base was significant.

Security Should Be First Class

This incident serves as a powerful reminder, especially for teams building tools that handle civic data, support political engagement, or are simply used by a large number of people:

Security cannot be an afterthought.

It has to be a first-class concern, baked into the development process from day one. Simple configuration flags, often overlooked during deployment checklists, can have devastating consequences.

If you're working on systems that touch sensitive user data or play a role in important civic processes, you have a heightened responsibility. This means being meticulous. Double-check your production settings.

Ensure DEBUG is False. Review environment variables. Audit what information is being exposed through APIs or error pages. Pretend you're an attacker for a moment and probe the obvious points – you might be surprised what you find due to a simple oversight.

Hell, just automate it. These kinds of critical settings and potential information leaks can often be checked statically right in your IDE before you even push your code. They can and should be analysed by tools in your code repository (like linters or security scanners) as part of your pull request process, and certainly before they are deployed to production in your CI/CD pipeline.

This wasn't a sophisticated hack; it was a basic, preventable misconfiguration.

It highlights that the lowest hanging fruit for attackers often comes from these simple oversights. The team's rapid response is commendable, but the best scenario is preventing the leak entirely.

Our users' trust, and their data, depend on it.