Challenge 3: Audit a Production settings.py — Possible Solution
====================================================================

# BEFORE — deployed to production as-is

DEBUG = True
ALLOWED_HOSTS = []

# AFTER — corrected for production

DEBUG = False
ALLOWED_HOSTS = ["www.mysite.com", "mysite.com"]

WHAT'S WRONG WITH EACH SETTING
---------------------------------

1. DEBUG = True in production
   Django's debug page shows a full stack trace, every local variable's
   value at the point of the error, the complete request/response data,
   and a list of installed apps and settings whenever an unhandled
   exception occurs. In production, this means any visitor who manages
   to trigger an error (deliberately or by accident) sees deep internal
   detail about the application's source code and configuration — this
   is precisely the "verbose error messages revealing implementation
   details" pattern the OWASP course's Security Misconfiguration chapter
   warned about. The fix is DEBUG = False, which shows a generic, safe
   error page instead of the debug page to real visitors.

2. ALLOWED_HOSTS = [] in production
   With DEBUG = False, an empty ALLOWED_HOSTS actually causes Django to
   refuse every single request outright — but if DEBUG were left True
   while ALLOWED_HOSTS stayed empty, Django would accept requests with
   any Host header at all, which opens the door to HTTP Host header
   attacks (an attacker crafts a request with a spoofed Host header to
   manipulate password-reset links, cache poisoning, or other logic that
   trusts the Host header). ALLOWED_HOSTS should list the actual
   domain(s) the site is meant to serve — here, the real production
   domain(s) like "www.mysite.com" and "mysite.com" — so Django rejects
   any request claiming to be for a different, unrecognized host.

WHY THIS WORKS
--------------
- These two settings are meant to work together as production
  safeguards: DEBUG = False stops sensitive internal detail from leaking
  through error pages, and a correctly populated ALLOWED_HOSTS stops
  Django from processing requests for hostnames it was never meant to
  serve.
- Neither setting has a "safe default" that works for both development
  and production simultaneously — the standard practice is to keep
  DEBUG = True only in a local development settings file/environment
  variable, and ensure the actual production deployment always sets
  DEBUG = False with a real ALLOWED_HOSTS list, ideally driven by an
  environment variable (per the TypeScript course's Configuration
  Management chapter) rather than a hardcoded value committed to source
  control.