Notifications
Clear all
Topic starter
01/08/2026 10:44 pm
TL;DR: Flask code that sets cookies without explicit Secure, HttpOnly, and SameSite flags was found by Semgrep, then the pattern was measured across 715 Flask apps on GitHub and 18 repositories with 66 instances were identified. The issue is not exotic exploitation, but avoidable session handling that leaves cookies more exposed to XSS and CSRF than most teams intend.
NHIMG editorial — based on content published by Semgrep: Cookies! Secure flags, HttpOnly, SameSite, and a new Flask check
By the numbers:
- The check fires in 18 repositories for a total of 66 instances.
Questions worth separating out
Q: How should teams implement secure cookie policy in Flask applications?
A: Set a secure default for every cookie that carries authenticated state, and make Secure, HttpOnly, and SameSite explicit in code.
Q: Why do missing cookie flags create identity risk in web apps?
A: Because cookies often represent the browser-side proof of an authenticated session.
Q: What do security teams get wrong about cookie hardening?
A: They often treat cookie flags as optional polish rather than part of the authentication boundary.
Practitioner guidance
- Enforce explicit cookie flags in code review Require Secure, HttpOnly, and SameSite to be stated on every cookie-setting call unless a documented exception exists.
- Standardise a safe baseline for session cookies Define an application-wide default for authenticated cookies, then override only when a business case is documented.
- Add static checks to the release gate Run a Semgrep rule or equivalent policy check in CI so partial cookie configurations are caught before deployment.
What's in the full article
Semgrep's full post covers the implementation detail this analysis intentionally leaves for the source:
- The exact Semgrep rule logic for detecting missing secure, httponly, and samesite keyword arguments in Flask calls
- The code examples showing acceptable explicit disablement and partial flag combinations
- The repository sampling method behind the 715-app test set and the 66-instance finding
- The practical check output you can use to reproduce the rule in your own codebase
👉 Read Semgrep's analysis of Flask cookie security flags and missing session protections →
Flask cookie security flags: are your session controls keeping up?
Explore further
01/08/2026 10:53 pm
Explicit cookie attributes are a session governance control, not a cosmetic hardening step. When teams leave Secure, HttpOnly, and SameSite implicit, they are outsourcing policy to framework defaults and browser behaviour. That weakens auditability and makes session handling harder to reason about during review, testing, and incident response. In identity programmes, the control point is the cookie issuance path itself, because that is where authenticated state becomes governable or exposed.
A question worth separating out:
Q: How can organisations tell whether cookie policy is actually working?
A: Look for every session-bearing cookie to have an explicit security declaration in code, and verify that CI blocks partial configurations. If exception cases exist, they should be rare, documented, and time-bound. A healthy programme can show both technical enforcement and a clear record of the few approved deviations.
👉 Read our full editorial: Flask cookie security flags expose a common web session gap
