DEBUG وSECRET_KEY وALLOWED_HOSTS

Three settings in settings.py can sink a production site if you get them wrong. Let us tame DEBUG, SECRET_KEY, and ALLOWED_HOSTS together. 🔒

When DEBUG is True, Django shows detailed error pages with your code, settings, and traceback. That is gold in dev but a gift to attackers in production.

In production, set DEBUG to False so users see a generic 500 page instead of your internals. Never ship a live site with DEBUG on.

The SECRET_KEY is the seed Django uses to sign sessions, CSRF tokens, and password resets. Leak it and an attacker can forge any of them.

Never commit your real SECRET_KEY to git. Load it from an environment variable so the value lives outside your code.

Need a fresh SECRET_KEY? Django ships a helper that returns a long, random, hard-to-guess string for you to store securely.

ALLOWED_HOSTS lists the domains your site is allowed to serve. It blocks HTTP Host header attacks that try to trick your app with a fake hostname.

Fill ALLOWED_HOSTS with the exact domains your site answers to. With DEBUG off, any request to an unlisted host gets a 400 error.

Setting ALLOWED_HOSTS to the wildcard accepts any host header and defeats the protection. Use it only for quick local tests, never in production.

The clean pattern is one source of truth: read DEBUG, SECRET_KEY, and hosts from environment variables so the same code runs safely everywhere.

Django can audit these settings for you. The check --deploy command flags an unsafe DEBUG, weak key, or open hosts before you ship.

Time to test your instinct about production settings.

You locked down the basics: DEBUG off, a secret key kept out of git, and ALLOWED_HOSTS scoped to your domains. Run check --deploy and you are off to a safe start. 🎉