Hardcoded SECRET_KEY
Part of Security, which counts for 30% of the overall score. When this check fires it deducts 15 points from that category, once per scan, no matter how many places it turns up.
What it detects
SECRET_KEY is assigned a literal string (or an env lookup with a real-looking hardcoded fallback) instead of being read from the environment with no default. Django uses this key to sign sessions, password-reset tokens, and CSRF tokens, so anyone with the source can forge all three.
Why it matters
SECRET_KEY signs Django's session cookies, password-reset tokens, and (by default) CSRF tokens. A hardcoded value, or an environment lookup with a real-looking fallback, means anyone who can read the source (a git history, a leaked repo, a public fork) can forge sessions, mint password-reset links for any account, and generate valid CSRF tokens. Rotating a leaked key after the fact does not undo whatever was forged while it was live.
How to fix it
Read SECRET_KEY from the environment with no literal fallback: SECRET_KEY = os.environ["SECRET_KEY"], so a deploy that forgets to set it fails to start instead of running with a known key. Generate a new key with django.core.management.utils.get_random_secret_key() and store it in your secret manager or deploy environment, never in source. Rotate any key that was ever committed.
The paid report includes a ready-to-paste prompt for your AI coding agent for every check it finds, pointed at the exact findings from your scan. See pricing
Does your repo trip this check?
Paste a GitHub URL or drop a project folder. Scans run in your browser and take seconds.
Scan your repo