Rule Information
Tags
pythondjangocookiessecurity-misconfigurationhttponlysecuresamesiteauditCWE-614CWE-1004OWASP-A05
Interactive Playground
Experiment with the vulnerable code and security rule below. Edit the code to see how the rule detects different vulnerability patterns.
pathfinder scan --ruleset python/PYTHON-DJANGO-SEC-070 --project .1
2
3
4
5
6
7
8
9
rule.py
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
About This Rule
Understanding the vulnerability and how it is detected
This rule detects insecure cookie configurations in Django applications by auditing calls to response.set_cookie() that may be missing critical security flags: Secure, HttpOnly, and SameSite.
Cookies without the Secure flag are transmitted over unencrypted HTTP connections, exposing them to network eavesdropping. Cookies without the HttpOnly flag are accessible via document.cookie in JavaScript, enabling session cookie theft through XSS attacks. Cookies without the SameSite flag can be sent in cross-site requests, facilitating Cross-Site Request Forgery (CSRF) attacks.
This rule uses pattern matching on calls to *.set_cookie() to audit all cookie setting calls and flag those missing the recommended security attributes. For session cookies specifically, Django's global settings SESSION_COOKIE_SECURE, SESSION_COOKIE_HTTPONLY, and SESSION_COOKIE_SAMESITE should also be set.
Security Implications
Potential attack scenarios if this vulnerability is exploited
1
Session Hijacking via Network Interception
Cookies without the Secure flag are transmitted in plaintext over HTTP. An attacker on the same network (coffee shop WiFi, corporate network with a compromised switch) can intercept session cookies using passive eavesdropping, enabling session hijacking without any interaction with the application.
2
Session Cookie Theft via XSS
Cookies without the HttpOnly flag are readable by JavaScript via document.cookie. Any XSS vulnerability in the application can be used to exfiltrate session cookies to attacker-controlled servers, enabling account takeover. HttpOnly prevents this specific attack path even when XSS is present.
3
Cross-Site Request Forgery via Unprotected Cookies
Cookies without SameSite=Lax or SameSite=Strict are sent by browsers in cross-site requests. Combined with insufficient CSRF token protection, this enables attackers to craft pages that trigger state-changing actions in the application on behalf of authenticated users.
4
Cookie Theft via Mixed Content
Even on HTTPS pages, cookies without the Secure flag can be exposed if any resource on the page is loaded over HTTP (mixed content). Browsers may send non-Secure cookies with HTTP requests to the same domain, creating an exposure window even on otherwise HTTPS deployments.
How to Fix
Recommended remediation steps
- 1Set secure=True on all cookies that should only be transmitted over HTTPS connections.
- 2Set httponly=True on all session and authentication cookies to prevent JavaScript access.
- 3Set samesite='Lax' as the minimum SameSite policy; use samesite='Strict' for cookies not needed in cross-site top-level navigation.
- 4Configure Django's global session and CSRF cookie settings: SESSION_COOKIE_SECURE, SESSION_COOKIE_HTTPONLY, SESSION_COOKIE_SAMESITE, CSRF_COOKIE_SECURE.
- 5Set appropriate max_age or expires values to limit the lifetime of cookies and reduce the window of exposure for stolen cookies.
Detection Scope
How Code Pathfinder analyzes your code for this vulnerability
This rule uses QueryType pattern matching on calls("*.set_cookie") to audit all cookie-setting calls in Django views and middleware. It checks for the presence of the secure, httponly, and samesite keyword arguments and flags calls where these are absent or set to False/None. The .where() clause constrains matches to Python files in Django project structures. This is an audit rule rather than a taint-based rule -- it flags all set_cookie() calls regardless of what value is being stored in the cookie.
Compliance & Standards
Industry frameworks and regulations that require detection of this vulnerability
OWASP Top 10
A05:2021 - Security Misconfiguration
CWE Top 25
CWE-614 and CWE-1004 - Cookie security flags
PCI DSS v4.0
Requirement 6.4.1 - all cookies that do not have the Secure attribute must be justified
NIST SP 800-53
SC-8: Transmission Confidentiality and Integrity; SC-23: Session Authenticity
GDPR Article 32
Technical measures to ensure security of personal data processing including session management
References
External resources and documentation
Similar Rules
Explore related security rules for Python
CRITICAL
Django SQL Injection via cursor.execute()
User input flows to cursor.execute() without parameterization, enabling SQL injection attacks.
CRITICAL
Django SQL Injection via QuerySet.raw()
User input flows to QuerySet.raw() without parameterization, enabling SQL injection through Django's ORM raw query interface.
HIGH
Django SQL Injection via QuerySet.extra()
User input flows to QuerySet.extra() without parameterization, enabling SQL injection through Django's legacy ORM extension interface.
Frequently Asked Questions
Common questions about Django Insecure Cookie Settings via set_cookie()
Both are needed for complete coverage. Django's SESSION_COOKIE_SECURE and
CSRF_COOKIE_SECURE settings protect the built-in session and CSRF cookies.
Custom cookies set via response.set_cookie() require the secure parameter to
be passed explicitly, as they are not covered by the session cookie settings.
Set both: the global Django settings for built-in cookies and explicit flags
for custom cookies.
SameSite=Lax sends cookies on top-level GET navigation from other sites (e.g.,
clicking a link from an email). SameSite=Strict never sends the cookie on
cross-site requests, even top-level navigation. Lax is the recommended default
for session cookies because it allows users to follow external links and arrive
at the site already logged in. Strict provides better CSRF protection but may
confuse users who click links from external sites and appear logged out.
For cookies that genuinely need JavaScript access (analytics, user preferences
accessed by client-side code), httponly=False is acceptable -- but document this
explicitly in code comments and ensure those cookies do not contain session tokens
or authentication state. Authentication and session cookies must always have
httponly=True.
No. SameSite cookies are a defense-in-depth measure but not a complete CSRF
replacement. Some browsers do not fully support SameSite, older browsers ignore
it entirely, and some legitimate cross-site requests (OAuth, payment provider
callbacks) may need to carry cookies. Django's CSRF middleware should remain
enabled. SameSite cookies reduce the CSRF attack surface but do not eliminate it.
Django's global settings (SESSION_COOKIE_SECURE, etc.) apply only to cookies
set through Django's session framework and CSRF middleware. They have no effect
on cookies set directly via response.set_cookie(). Each set_cookie() call must
include the security flags explicitly.
Check the package's documentation for cookie security configuration options.
Many packages support settings like COOKIE_SECURE or allow wrapping their
response processing. If the package does not support security flags, submit
a bug report. In the interim, you can wrap the package's views with middleware
that adds security flags to all Set-Cookie headers.
New feature
Get these findings posted directly on your GitHub pull requests
The Django Insecure Cookie Settings via set_cookie() rule runs in CI and posts inline review comments on the exact lines — no dashboard, no SARIF viewer.