Skip to content

VNX-614: Sensitive Cookie in HTTPS Session Without 'Secure' Attribute

Reports session, token and auth cookies sent without Secure: Django/Flask *_COOKIE_SECURE = False, set_cookie without secure=True, res.cookie, reply.setCookie or cookie.serialize without secure: true, secure: false in cookie options, document.cookie without ; Secure, Java cookies and Spring ResponseCookie without setSecure/secure(true), and server.servlet.session.cookie.secure=false.

Updated 02 Nov 2026Checked against cli@de9b52a
Field Value
Rule ID VNX-614
Severity High
SARIF level error
Kind sast
Languages Java, JavaScript / TypeScript, Python
CWE CWE-614
CAPEC CAPEC-66
ATT&CK T1190
CWSS vector CWSS:1.0/TI:H/AP:A/AL:A/IC:N/FC:LT/RP:N/RL:A/AV:I/AS:N/IN:A/SC:A/BI:H/DI:H/EX:H/EC:N/P:H
Tags session secure-flag cwe-614
Source internal/sast/rules/vnx-614.rego

Overview

VNX-614 maps to CWE-614: Sensitive Cookie in HTTPS Session Without ‘Secure’ Attribute.

  • Python: SESSION_COOKIE_SECURE, CSRF_COOKIE_SECURE or REMEMBER_COOKIE_SECURE set to False (assignment, app.config[...], config.update(...)); set_cookie(..., secure=False); set_cookie() of a session, token, JWT, auth, remember-me, login, user-id or CSRF cookie with no secure= argument.
  • JavaScript/TypeScript: secure: false in cookie or session options; res.cookie()/ctx.cookies.set() of such a cookie with no options or an options literal without secure; document.cookie = "token=..." without ; Secure.

Not reported: a cookie being cleared (empty or null value, max_age=0, setMaxAge(0)), secure taken from a variable or the environment, options passed as a variable or spread, non-sensitive cookies (theme, language) and flag values (1, true), Flask’s default-config dict, development settings files (settings/local.py, dev.py), secure: false away from any cookie (SMTP clients), and tests. VNX-SEC-013, the catch-all cookie-flag rule, leaves the Secure lines this rule reports to it, so a missing Secure flag is one finding.

Why This Matters

A cookie without Secure is also sent over plain HTTP, for example on the first http:// request before a redirect. Anyone on the network path can then read the session or token and take over the account.

What Gets Flagged

SESSION_COOKIE_SECURE = False
response.set_cookie("auth_token", token, httponly=True)
res.cookie('token', token)
app.use(session({ cookie: { httpOnly: true, secure: false } }))
document.cookie = "access_token=" + token + "; path=/";
Cookie session = new Cookie("JSESSIONID", id);          // no setSecure(true) follows
ResponseCookie.from("AUTH_TOKEN", jwt).httpOnly(true).build();
server.servlet.session.cookie.secure=false

Remediation

  1. Set SESSION_COOKIE_SECURE = True / CSRF_COOKIE_SECURE = True in production settings.
  2. Pass secure=True (Python) or secure: true (Express, Koa) for every session and authentication cookie, and serve the site only over HTTPS with HSTS.
  3. For a confirmed false positive, add a # vulnetix-ignore: VNX-614 comment on the line.

References

Suppressing this rule

Put a nosec comment on the line, or on line 1 to cover the whole file. Use the comment marker of the file’s language (#, //, -- or ;):

# nosec vnx-614
// nosec vnx-614

Or record an ignore rule: vulnetix ignore add --rule vnx-614 --reason "...". See Suppressing findings.

Edit this pageSources: cli/internal/sast/rules/vnx-614.rego, cli/internal/sast/docs/vnx-614.md
esc
↑ ↓ move↵ openSearches in your browser. A key like autonomy.max or a code like threshold_required jumps straight to it.