Django Secret Key
ID |
django_secret_key |
Severity |
high |
Vendor |
Django |
Family |
Generic secret |
Description
A secret key for a particular Django installation. This is used to provide cryptographic signing, and should be set to a unique, unpredictable value.
Security
| Keep this value secret. Running Django with a known SECRET_KEY defeats many of Django’s security protections, and can lead to privilege escalation and remote code execution vulnerabilities. |
The secret key is used for:
-
All sessions if you are using any other session backend than django.contrib.sessions.backends.cache, or are using the default get_session_auth_hash().
-
All messages if you are using CookieStorage or FallbackStorage.
-
All PasswordResetView tokens.
-
Any usage of cryptographic signing, unless a different key is provided.
Accidentally checking-in the key to source control repositories could compromise your Django server, allowing an attacker to be able to modify the cookies sent by the application.
Mitigation / Fix
-
Remove the
SECRET_KEYfrom the source code or committed configuration file. -
Follow your policy for handling leaked secrets, which typically require revoking the secret in the target system(s). To revoke the key, a new secret needs to be generated. All sessions or cookies signed with the key will be invalided.
| When rotating your secret key, you should move the old key to SECRET_KEY_FALLBACKS temporarily. Secret keys are not used for passwords of users and key rotation will not affect them. See Settings SECRET KEY for more information. |
-
If under a git repository, you may remove unwanted files from the repository history using tools like
git filter-repoorBFG Repo-Cleaner. You may follow the procedure listed here for GitHub.
|
You should consider any sensitive data in commits with secrets as compromised. Remember that secrets may be removed from history in your projects, but not in other users' cloned or forked repositories. |