Skip to content

VNX-GO-030: Missing Secure flag on cookie

Detects a cookie sent to the browser without Secure: an http.Cookie, fiber.Cookie or gorilla sessions.Options literal with Secure absent or false, gin SetCookie with secure=false, a hand-written Set-Cookie header without Secure, csrf.Secure(false), or a gorilla cookie store whose Options are never set.

Updated 02 Nov 2026Checked against cli@de9b52a
Field Value
Rule ID VNX-GO-030
Severity Medium
SARIF level warning
Kind sast
Languages Go
CWE CWE-614
CAPEC CAPEC-63
ATT&CK T1059.007
CWSS vector CWSS:1.0/TI:M/AP:A/AL:A/IC:N/FC:LT/RP:N/RL:A/AV:I/AS:N/IN:A/SC:A/BI:M/DI:H/EX:M/EC:N/P:C
Tags cookie secure session
Source internal/sast/rules/vnx-go-030.rego

Overview

This rule flags Go code that creates an http.Cookie struct without setting Secure: true. The Secure attribute instructs browsers to transmit the cookie only over HTTPS connections. Without it, any cookie, including session tokens, authentication tokens, and CSRF tokens, can be intercepted in plaintext by a network attacker performing a passive eavesdrop or an active man-in-the-middle attack. This maps to CWE-614: Sensitive Cookie in HTTPS Session Without ‘Secure’ Attribute.

This is particularly dangerous for session management. Even if your application enforces HTTPS at the server level, a cookie without the Secure flag can be exposed the moment a user’s browser makes any HTTP request to your domain, for example, by following a link to http:// rather than https://. Mixed-content scenarios and HTTP-to-HTTPS redirect chains are common in real deployments and create a reliable interception window.

Why This Matters

The Secure flag is a defense-in-depth control that operates at the browser level: the browser itself refuses to send the cookie over unencrypted channels regardless of the application’s redirect logic. Omitting it means the protection depends entirely on every HTTP request always redirecting to HTTPS, every link in the application using https://, and no intermediary ever downgrading the connection, assumptions that frequently fail in practice.

Passive interception on open Wi-Fi networks, HTTP downgrade attacks such as SSLstrip, and DNS-based interception can all expose session cookies that lack the Secure attribute. OWASP explicitly requires the Secure flag on all sensitive cookies in its Session Management Cheat Sheet, and CAPEC-63 (Simple Script Injection) documents cookie theft as a standard attack goal achievable when this flag is absent.

What Gets Flagged

A cookie the server sends without the Secure attribute.

// FLAGGED: Secure field not set
cookie := http.Cookie{
    Name:     name,
    Value:    value,
    HttpOnly: true,
}
http.SetCookie(w, &cookie)

// FLAGGED: gin, sixth argument is secure
c.SetCookie("session", token, 3600, "/", "", false, true)

// FLAGGED: new(http.Cookie) sent without .Secure being set
cookie := new(http.Cookie)
cookie.Name = "token"
c.SetCookie(cookie)

Not flagged: Secure set to true or any expression (r.TLS != nil, a config value), deletion cookies (negative MaxAge, epoch Expires), cookies a client sends (req.AddCookie, a jar), test files.

Remediation

  1. Always set Secure: true on cookies that carry session or authentication data:

    // SAFE: Secure flag set
    cookie := &http.Cookie{
        Name:     "session_id",
        Value:    sessionToken,
        HttpOnly: true,
        Secure:   true,
        SameSite: http.SameSiteLaxMode,
        Path:     "/",
        MaxAge:   3600,
    }
    http.SetCookie(w, cookie)
  2. Set HttpOnly: true at the same time to prevent JavaScript access, and configure SameSite to reduce CSRF exposure:

    // SAFE: all recommended security attributes present
    func setSessionCookie(w http.ResponseWriter, token string) {
        http.SetCookie(w, &http.Cookie{
            Name:     "session",
            Value:    token,
            Path:     "/",
            MaxAge:   int(24 * time.Hour / time.Second),
            HttpOnly: true,
            Secure:   true,
            SameSite: http.SameSiteStrictMode,
        })
    }
  3. Use a helper function that enforces secure defaults so individual call sites cannot accidentally omit the Secure flag:

    // SAFE: centralized cookie factory enforces Secure
    func newSecureCookie(name, value string, maxAge int) *http.Cookie {
        return &http.Cookie{
            Name:     name,
            Value:    value,
            Path:     "/",
            MaxAge:   maxAge,
            HttpOnly: true,
            Secure:   true,
            SameSite: http.SameSiteLaxMode,
        }
    }

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-go-030
// nosec vnx-go-030

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

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