Skip to content

DJANGO_DEBUG defaults to True: a missing env var fails open to debug mode in production #20

@erskingardner

Description

@erskingardner

Impact

DEBUG defaults to True when DJANGO_DEBUG is unset:

DEBUG = env_bool("DJANGO_DEBUG", True)

All of the production safety guards in config/settings.py are gated on not DEBUG — they only fire when DEBUG is already False:

  • SECRET_KEY must be set (config/settings.py:23)
  • ALLOWED_HOSTS must be tight (config/settings.py:30)
  • CSRF_TRUSTED_ORIGINS must be set (config/settings.py:34)
  • DATABASE_URL must be set and non-SQLite (config/settings.py:80, config/settings.py:89)
  • SESSION_COOKIE_SECURE / CSRF_COOKIE_SECURE / HSTS default on (config/settings.py:119, config/settings.py:126)

This means the configuration fails open: if DJANGO_DEBUG is simply absent from the environment (a commented-out or missing line in .env, a forgotten variable in a new deployment path, a one-off docker run without the env file), the app silently boots with DEBUG=True, the dev SECRET_KEY, the SQLite fallback, and none of the guards raising. For an app whose whole purpose is to hold highly sensitive forensic data (bearer tokens, engine ids, account refs, message ids, payload digests, IPs, user agents, raw upload bodies), running with DEBUG=True exposes full settings and data-bearing tracebacks on any unhandled error.

.env.example does set DJANGO_DEBUG=0 and docker-compose.yml loads it via env_file, so the documented happy path is safe — but the default should be the safe value so that a missing var fails closed, not open.

Code pointers

  • config/settings.py:21DEBUG = env_bool("DJANGO_DEBUG", True).
  • config/settings.py:23-90 — every production guard is conditioned on not DEBUG, so they do nothing when the var is missing and DEBUG stays True.

Expected behavior

A missing DJANGO_DEBUG should fail closed (production-safe), so that an operator must opt in to debug mode rather than opt out of it.

Suggested fix

  • Default DEBUG to False: DEBUG = env_bool("DJANGO_DEBUG", False), and set DJANGO_DEBUG=1 (or true) in the local just workflow / dev .env so local development is unaffected.
  • Alternatively, require DJANGO_DEBUG to be set explicitly and raise ImproperlyConfigured if it is absent, so neither mode is implicit.
  • Add a test asserting that, with a representative production-style environment but DJANGO_DEBUG unset, the app does not come up in debug mode.

Metadata

Metadata

Assignees

No one assigned

    Labels

    MEDIUMSeverity: important bug or performance issue with bounded impactbugSomething isn't working

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions