[CRITICAL] Weak default SECRET_KEY enables full system compromise in production deployments

[namann5]

Description

Severity: CRITICAL
CWE: CWE-798 (Use of Hard-coded Credentials)
Affected file: core/settings.py:27

Vulnerability

Weak default SECRET_KEY

In core/settings.py:27, SECRET_KEY falls back to a hardcoded value when the environment variable is not set:

SECRET_KEY = os.environ.get('SECRET_KEY', 'django-insecure-dev-key-for-local-testing')

This key is publicly known (visible in source code). If any production deployment fails to set SECRET_KEY, Django silently uses this weak key. An attacker can then:

• Forge session cookies — impersonate any user
• Forge CSRF tokens — perform state-changing actions on behalf of victims
• Bypass OTP verification — OTP hashes use settings.SECRET_KEY as HMAC salt (game/views.py:901-903, 1048-1050)
• Forge password reset tokens — take over any account

The key is used extensively as a cryptographic salt in the OTP system:

# game/views.py:901-903 (register_view)
otp_hash = hashlib.sha256(
    f"{otp}:{settings.SECRET_KEY}".encode()
).hexdigest()

# game/views.py:1048-1050 (verify_otp)
entered_otp_hash = hashlib.sha256(
    f"{entered_otp}:{settings.SECRET_KEY}".encode()
).hexdigest()

# game/views.py:1186-1188 (resend_otp)
otp_hash = hashlib.sha256(
    f"{otp}:{settings.SECRET_KEY}".encode()
).hexdigest()

Missing Content Security Policy (amplifies risk)

No CSP headers configured. The app loads chess piece images from external CDN (images.chesscomfiles.com) in board.js:20. Without CSP, a compromised CDN can inject arbitrary JS.

Proposed Approach

Fix 1: Enforce strong SECRET_KEY at startup

In core/settings.py, raise ImproperlyConfigured if the default key is used outside debug mode.

Fix 2: Add Content Security Policy middleware

Create middleware that injects CSP headers allowing only 'self' and the chess.com CDN for images.

Impact

Successful exploitation allows complete account takeover of any user including administrators.

Request

Please assign this issue to me (@namann5). I have already prepared a fix branch and will submit a PR shortly.

[coderabbitai]

⚠️ Possible Duplicate Issue(s)

• [Security] Insecure default for Django SECRET_KEY in Production in core/settings.py #1829

🔗 Related PRs

#1307 - fix: sanitize move notation rendering and harden CSRF cookie [merged]
#1761 - Fix IP spoofing vuln in password reset rate limiting by adding proxy … [merged]

---

📝 Issue Planner

_{Check the box below or use the @coderabbitai plan command to generate an implementation plan and prompts that you can use with your favorite coding assistant.}

• Create Plan

---

🧪 Issue enrichment is currently in open beta.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord!

[namann5]

@maintainers — please assign this issue to me . I have already prepared the fix on branch \ix/enforce-secure-secret-key-and-csp\ with the following approach:

Fix 1: In \core/settings.py, added a startup check that raises \ImproperlyConfigured\ if the weak default SECRET_KEY is used with DEBUG=False — preventing accidental production deployment with the hardcoded key.

Fix 2: Added \core/middleware.py\ with \ContentSecurityPolicyMiddleware\ that injects strict CSP headers: \default-src 'self', \img-src 'self' https://images.chesscomfiles.com data:, \script-src 'self', \rame-ancestors 'none', \�ase-uri 'self', \orm-action 'self'.

Once assigned, I will push the branch and submit the PR.

[coderabbitai]

Coding Plan

Summary

• fail fast on insecure secret_key when not in debug mode, preventing silent production misconfigs
• custom csp middleware instead of third party package since needs are simple and well defined
• csp whitelist derived directly from actual external resources found in codebase exploration

Design Choices

Design Choice 1: custom middleware over third party csp package

Options Considered:

1. use django-csp package
2. write custom middleware

Chosen Option: 2

Rationale: going with custom middleware instead of django-csp to avoid adding a dependency for what amounts to ~20 lines of code.

💡 User Tips

Regenerate the plan with different choices with @coderabbitai <feedback>.

Implementation Steps

Phase 1: enforce secret_key at startup

make the app fail fast if someone deploys to prod without setting a real secret key. this prevents silent fallback to the known insecure default.

add secret_key validation in settings

validate that the hardcoded fallback isnt used when debug is false

• in core/settings.py after the SECRET_KEY and DEBUG assignments, add a check that raises django.core.exceptions.ImproperlyConfigured if the key equals the insecure default and DEBUG is False
• keep the fallback working for local dev (DEBUG=True) so devs dont need to set env vars just to run locally
• error message should be clear about what to do: set SECRET_KEY env var

🤖 Prompt for AI agents

in `core/settings.py`, add a startup validation check after the SECRET_KEY and
DEBUG assignments.

- import `django.core.exceptions.ImproperlyConfigured` (or use it from the
django.core.exceptions module)
- check if SECRET_KEY equals the insecure hardcoded fallback value AND DEBUG is
False
- if both conditions are true, raise `ImproperlyConfigured` with a clear message
telling the developer to set the SECRET_KEY env var
- do not raise when DEBUG is True so local dev still works without requiring env
vars to be set

Phase 2: add content security policy

create custom middleware to inject csp headers. going with custom middleware instead of django-csp to avoid adding a dependency for what amounts to ~20 lines of code.

Task 1: create csp middleware

new middleware class that adds content-security-policy header to responses

• create core/middleware.py with a ContentSecurityPolicyMiddleware class
• use django's standard middleware pattern (init takes get_response, call processes request/response)
• build csp header with these directives based on what the app actually loads:
  • default-src 'self'
  • script-src 'self' cdnjs.cloudflare.com (chess.js)
  • style-src 'self' 'unsafe-inline' fonts.googleapis.com (inline styles exist in templates)
  • font-src 'self' fonts.gstatic.com
  • img-src 'self' images.chesscomfiles.com data: (chess pieces + any base64)
  • connect-src 'self'
  • frame-ancestors 'none'

Task 2: register middleware in settings

add the new middleware to the stack

• in core/settings.py add 'core.middleware.ContentSecurityPolicyMiddleware' to MIDDLEWARE list
• place it right after SecurityMiddleware (position 2) so it runs early in the response phase

🤖 Prompt for AI agents

this phase adds a csp middleware and wires it into the django middleware stack.

**task 1: create `core/middleware.py`**
- define a `ContentSecurityPolicyMiddleware` class using django's standard
middleware pattern
  - `__init__` accepts `get_response` and stores it
- `__call__` calls `get_response(request)`, then sets the
`Content-Security-Policy` header on the response before returning it
- set the `Content-Security-Policy` header with the following directives:
  - `default-src 'self'`
  - `script-src 'self' cdnjs.cloudflare.com`
  - `style-src 'self' 'unsafe-inline' fonts.googleapis.com`
  - `font-src 'self' fonts.gstatic.com`
  - `img-src 'self' images.chesscomfiles.com data:`
  - `connect-src 'self'`
  - `frame-ancestors 'none'`

**task 2: register in `core/settings.py`**
- add `'core.middleware.ContentSecurityPolicyMiddleware'` to the MIDDLEWARE list
- insert it at position 2, right after SecurityMiddleware

Research

django 6.x app deployed on vercel. settings in core/settings.py with IS_PRODUCTION flag keyed off VERCEL_ENV. no custom middleware exists anywhere, just django builtins plus whitenoise. external resources loaded: chess piece images from images.chesscomfiles.com, fonts from google, chess.js from cdnjs. otp system uses secret_key as hash salt across register/verify/resend flows in game/views.py.

---

🚀 Next Steps

🤖 All AI agent prompts combined

Task: 1

in `core/settings.py`, add a startup validation check after the SECRET_KEY and
DEBUG assignments.

- import `django.core.exceptions.ImproperlyConfigured` (or use it from the
django.core.exceptions module)
- check if SECRET_KEY equals the insecure hardcoded fallback value AND DEBUG is
False
- if both conditions are true, raise `ImproperlyConfigured` with a clear message
telling the developer to set the SECRET_KEY env var
- do not raise when DEBUG is True so local dev still works without requiring env
vars to be set
===============================================================================

Task: 2

this phase adds a csp middleware and wires it into the django middleware stack.

**task 1: create `core/middleware.py`**
- define a `ContentSecurityPolicyMiddleware` class using django's standard
middleware pattern
  - `__init__` accepts `get_response` and stores it
- `__call__` calls `get_response(request)`, then sets the
`Content-Security-Policy` header on the response before returning it
- set the `Content-Security-Policy` header with the following directives:
  - `default-src 'self'`
  - `script-src 'self' cdnjs.cloudflare.com`
  - `style-src 'self' 'unsafe-inline' fonts.googleapis.com`
  - `font-src 'self' fonts.gstatic.com`
  - `img-src 'self' images.chesscomfiles.com data:`
  - `connect-src 'self'`
  - `frame-ancestors 'none'`

**task 2: register in `core/settings.py`**
- add `'core.middleware.ContentSecurityPolicyMiddleware'` to the MIDDLEWARE list
- insert it at position 2, right after SecurityMiddleware

💡 Iterate on the plan with: `@coderabbitai` <feedback>

Example Feedback
- `@coderabbitai` You can skip phase 3. Add a simple unit test case for phase 2.
- `@coderabbitai` For design choice 1 go ahead with option 3 and replan.

---

💬 Have feedback or questions? Drop into our discord!

[kamalsolanki143]

Hii @chekr-max ,
I would like to work on this issue under GSSoC'26. Kindly assign it to me. Thank you