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.
Editorial analysis by NHI Mgmt Group, based on content published by Semgrep: “Bento check: keeping your cookies safe in Flask”.
Key questions
Q: How should teams handle cookies that do not explicitly set Secure, HttpOnly, and SameSite?
A: Treat missing cookie flags as a security decision, not a harmless omission.
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 are the signs that device security controls are being applied inconsistently?
A: Common warning signs include laptops left unlocked at desks, devices taken offsite without secure storage, and delayed operating system or software updates.
Practitioner guidance
- Enforce explicit cookie flags at issuance Require Secure, HttpOnly, and SameSite to be declared in every session cookie call unless a documented exception exists.
- Scan repositories for incomplete set_cookie() calls Use static analysis to find any Flask set_cookie() usage where one or more security attributes are missing, then route those findings to code review.
- Document approved cookie exceptions Maintain a short policy for when a cookie may intentionally disable Secure, HttpOnly, or SameSite, and require the rationale in code review.
Bottom line: Missing cookie flags turn routine session handling into a security gap because browser-managed cookies need explicit controls to resist script access and cross-site abuse.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
01/08/2026 10:53 pm
Cookie security is a session governance control, not a browser tuning preference. The article reinforces that Secure, HttpOnly, and SameSite each address a different exposure window in browser-managed session handling. When teams treat them as optional hints, they create a policy gap between authentication and session protection. Practitioners should treat cookie issuance as a governed control point, because the identity session is only as strong as the attributes attached to it.
A question worth separating out:
Q: Should organisations prefer explicit cookie policy or rely on framework defaults?
A: Prefer explicit policy every time. Framework defaults can help with usability, but they do not guarantee that every session cookie is issued with the right browser constraints. When access-bearing cookies are involved, the safer pattern is to make the intended posture visible in code and test for it in review.
👉 Read our full editorial: Flask cookie security flags expose a common web session gap