rspec/rules/S6687/secrets/rule.adoc

66 lines
1.8 KiB
Plaintext

include::../../../shared_content/secrets/description.adoc[]
== Why is this an issue?
include::../../../shared_content/secrets/rationale.adoc[]
=== What is the potential impact?
If a Django secret key leaks to an unintended audience, it can have serious
security implications for the corresponding application. The secret key is used
to sign cookies and other sensitive data so that an attacker could potentially
use it to perform malicious actions.
For example, an attacker could use the secret key to create their own cookies
that appear to be legitimate, allowing them to bypass authentication and gain
access to sensitive data or functionality.
In the worst-case scenario, an attacker could be able to execute arbitrary code
on the application and take over its hosting server.
== How to fix it
include::../../../shared_content/secrets/fix/revoke.adoc[]
In Django, changing the secret value is sufficient to invalidate any data that
it protected. It is important to not add the revoked secret to the
`SECRET_KEY_FALLBACKS` list. Doing so would not prevent previously protected
data from being used.
include::../../../shared_content/secrets/fix/vault.adoc[]
=== Code examples
==== Noncompliant code example
[source,python,diff-id=1,diff-type=noncompliant,subs="attributes"]
----
SECRET_KEY = 'r&lvybzry1*k+qq)=x-!=0yd5l5#1gxzk!82@ru25*ntos3_9^'
----
==== Compliant solution
[source,python,diff-id=1,diff-type=compliant,subs="attributes"]
----
import os
SECRET_KEY = os.environ["SECRET_KEY"]
----
//=== How does this work?
//=== Pitfalls
//=== Going the extra mile
== Resources
include::../../../shared_content/secrets/resources/standards.adoc[]
=== Documentation
* https://docs.djangoproject.com/en/4.2/ref/settings/#std-setting-SECRET_KEY[Django documentation] - Settings - SECRET_KEY
//=== Benchmarks