A public directory exposed a Django production stack

The finding

I found directory indexing enabled on a public server belonging to a uniform manufacturer. There was no authentication in front of it. The listing exposed source code, logs, configuration, database files, and certificate material from a Django deployment.

One file did most of the talking: settings.py.

It contained:

• the production Django SECRET_KEY
• an OpenAI API key
• MySQL database credentials
• Gmail SMTP credentials

The same directory also exposed:

• db.sqlite3
• cert.pem
• cert.key
• application source code
• operational logs and configuration files

This was enough information to understand the stack and identify several paths to real impact.

What those files could enable

The exact outcome would depend on which credentials were still active and how the services were configured. The credible risks included:

• access to production data through the exposed MySQL credentials
• unauthorized mail through the Gmail SMTP account
• abuse of the OpenAI account and its quota
• Django signing or session-related attacks if the exposed SECRET_KEY was in active use
• service impersonation if the private key matched a deployed certificate
• direct disclosure of records stored in db.sqlite3
• easier follow-on testing from the source code and logs

The issue was not an exotic application bug. A web server had been configured to list a directory that contained the production environment.

Disclosure timeline

• 29 April: sent the initial report to the development and IT contacts I could find
• 29 April: the company replied and started mitigation
• 3 to 12 May: followed up for a status update
• 13 May: the company confirmed the exposure was fixed and explained that no bounty was available
• 14 May: asked whether they could provide another form of acknowledgment
• 15 May: the company agreed to issue a responsible disclosure letter

The response stayed civil and useful. They fixed the exposure, confirmed the outcome, and provided written acknowledgment.

Remediation notes

Disabling directory indexing closes the immediate leak. It does not make the exposed secrets safe again. Every credential visible in that directory should be treated as compromised and rotated.

For a Django deployment, I would also check the following:

• load production secrets from environment variables or a secret manager
• keep database files, logs, certificates, and source archives outside the web root
• rotate the Django SECRET_KEY, database password, SMTP password, API keys, and TLS keys
• review access logs for requests to the exposed paths
• separate development artifacts from the production host
• add a deployment check that fails when directory indexing is enabled

The company fixed the public exposure. The harder part, and the part that matters after a leak like this, is making sure every exposed credential is replaced.