Rule Information
Tags
pythonflaskcookiesecurehttponlysamesitesession-managementconfigurationCWE-614OWASP-A05
CWE References
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-FLASK-AUDIT-009 --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
About This Rule
Understanding the vulnerability and how it is detected
This rule detects Flask response.set_cookie() calls where the secure or httponly flags are explicitly set to False. Cookies that carry session identifiers, authentication tokens, or any sensitive value must be protected by these flags.
The Secure flag prevents the browser from transmitting the cookie over unencrypted HTTP connections. Without it, a session cookie can be stolen by a passive network observer on any unencrypted path between the client and server -- public Wi-Fi, misconfigured proxies, or HTTP-to-HTTPS redirect chains. The HttpOnly flag prevents JavaScript running on the page (including injected XSS payloads) from accessing the cookie via document.cookie. Without it, a successful XSS attack instantly yields the session token.
The detection uses an Or pattern: Or(calls("*.set_cookie", match_name={"secure": False}), calls("*.set_cookie", match_name={"httponly": False})). This matches any object's set_cookie() method where either flag is explicitly disabled. The wildcard (*) on the receiver covers both response objects returned by Flask directly and response objects created via make_response().
Security Implications
Potential attack scenarios if this vulnerability is exploited
1
Session Hijacking via Network Eavesdropping
Without the Secure flag, a session cookie is sent over plain HTTP. On any network path that includes an unencrypted segment -- public Wi-Fi, HTTP-to-HTTPS redirect, mixed content -- a passive observer can capture the cookie and replay it to impersonate the authenticated user.
2
Session Hijacking via XSS
Without the HttpOnly flag, any JavaScript running on the page can read document.cookie and exfiltrate session tokens to an attacker-controlled server. A single XSS vulnerability anywhere on the domain can compromise every logged-in user's session.
3
Cross-Site Request Forgery Amplification
Cookies without the SameSite attribute (an additional flag not covered by this rule but worth setting) can be sent with cross-site requests, making CSRF attacks easier. Explicitly setting secure and httponly is the baseline; SameSite=Strict or Lax should also be configured.
4
Persistent Cookie Exposure
If a cookie is set without the Secure flag and the application later migrates to HTTPS, existing cookies issued to users during the HTTP period remain readable over plain HTTP until they expire or the user logs out.
How to Fix
Recommended remediation steps
- 1Set secure=True on all cookies that carry session identifiers, authentication tokens, or any sensitive data so they are never transmitted over plain HTTP.
- 2Set httponly=True on all session and authentication cookies so JavaScript cannot access them via document.cookie, limiting XSS damage.
- 3Set samesite='Strict' or samesite='Lax' to reduce CSRF risk. Use 'None' only for third-party contexts, and only in combination with secure=True.
- 4Configure Flask's global session cookie settings in app.config: SESSION_COOKIE_SECURE=True, SESSION_COOKIE_HTTPONLY=True, SESSION_COOKIE_SAMESITE='Lax'. These protect the built-in session cookie without requiring per-route set_cookie() calls.
- 5Review cookie usage during code review as a security-sensitive change and include it in your application's security checklist.
Detection Scope
How Code Pathfinder analyzes your code for this vulnerability
This rule uses Or(calls("*.set_cookie", match_name={"secure": False}), calls("*.set_cookie", match_name={"httponly": False})) to match any set_cookie() method call on any object where either the secure or httponly keyword argument is explicitly False. The wildcard receiver (*) covers response objects from both make_response() and direct route return-value manipulation. Calls that omit the secure or httponly argument entirely are not flagged by this rule -- consider those a separate audit (missing flag vs. explicit False). The rule operates at the call-site level without cross-file dataflow analysis.
Compliance & Standards
Industry frameworks and regulations that require detection of this vulnerability
OWASP Top 10
A05:2021 - Security Misconfiguration: set Secure and HttpOnly flags on session cookies
CWE Top 25
CWE-614 Sensitive Cookie Without Secure Attribute
PCI DSS v4.0
Requirement 6.2.4 -- protect session tokens from theft; Requirement 8.2.6 -- secure authentication credentials in transit
NIST SP 800-53
SC-8: Transmission Confidentiality -- protect session tokens during transport
References
External resources and documentation
Similar Rules
Explore related security rules for Python
MEDIUM
Flask CORS Wildcard Origin
Detects Flask-CORS configured with origins="*", allowing any domain to make cross-origin requests to the application.
CRITICAL
Flask Code Injection via eval()
User input from Flask request parameters flows to eval(). Replace with ast.literal_eval() for data parsing or json.loads() for structured input.
Frequently Asked Questions
Common questions about Flask Cookie Without Secure Flags
Explicitly setting secure=False or httponly=False is a deliberate override that is
almost never correct for sensitive cookies. Missing flags are a separate concern --
Flask's default for set_cookie() is to omit the flags (which browsers treat as not
set). A separate audit rule covering absent flags would complement this one. This rule
focuses on explicit disabling, which is the highest-confidence finding.
Yes, and you should. Cookies with the Secure flag are simply not sent over HTTP
connections -- they are only sent over HTTPS. If you have an HTTP endpoint, users
accessing it without HTTPS will not have the secure cookie sent, but they also will
not have it stolen in transit. Migrate fully to HTTPS and set the Secure flag on all
sensitive cookies.
Flask's built-in session cookie is configured via app.config: SESSION_COOKIE_SECURE,
SESSION_COOKIE_HTTPONLY, and SESSION_COOKIE_SAMESITE. This rule does not cover the
built-in session cookie because it uses a different configuration path. Always configure
those app.config values explicitly for the built-in session.
The SameSite attribute controls whether cookies are sent with cross-site requests.
SameSite=Strict prevents sending with any cross-site request. SameSite=Lax allows
sending with top-level navigations (links) but not with AJAX requests. SameSite=None
allows cross-site but requires Secure=True. Set Lax or Strict for session cookies to
reduce CSRF risk. This rule does not currently check for missing SameSite, but it is
a recommended addition.
Run: pathfinder ci --ruleset python/flask/PYTHON-FLASK-AUDIT-009 --project .
The rule outputs SARIF, JSON, or CSV and can post inline pull request comments on GitHub.
No. Flask-Login and Flask-Session use Flask's built-in session cookie infrastructure,
configured via app.config. This rule matches explicit set_cookie() calls in Python code.
For Flask-Login and Flask-Session, audit the SESSION_COOKIE_SECURE and related
app.config settings directly.
New feature
Get these findings posted directly on your GitHub pull requests
The Flask Cookie Without Secure Flags rule runs in CI and posts inline review comments on the exact lines — no dashboard, no SARIF viewer.