VNX-GO-035: Missing HttpOnly flag on cookie

Field	Value
Rule ID	VNX-GO-035
Severity	Medium
SARIF level	warning
Kind	sast
Languages	Go
CWE	CWE-1004
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 httponly session
Source	internal/sast/rules/vnx-go-035.rego

Overview

This rule flags any http.Cookie struct literal in Go source code that does not explicitly set HttpOnly: true. The HttpOnly attribute instructs browsers to withhold the cookie from JavaScript’s document.cookie API. Without it, any cross-site scripting (XSS) vulnerability, however minor, can be escalated by an attacker to steal session tokens, authentication cookies, or any other sensitive value stored in cookies. This is mapped to CWE-1004: Sensitive Cookie Without ‘HttpOnly’ Flag.

The flag has been supported by every major browser since 2009 and carries no functional cost for server-side session management. Its absence is almost always an oversight rather than a deliberate decision, making it a high-signal, low-noise indicator of a security gap.

Why This Matters

Cross-site scripting remains one of the most prevalent vulnerabilities in web applications. When an attacker can execute arbitrary JavaScript in a victim’s browser context, whether via a stored, reflected, or DOM-based XSS, the first action is typically to exfiltrate document.cookie. A session cookie without HttpOnly is directly readable, allowing the attacker to replay the cookie from another machine and hijack the session without ever obtaining the user’s password.

This pattern is actively exploited in the wild. Browser extensions, injected third-party scripts, and supply-chain compromises of JavaScript dependencies can all read non-HttpOnly cookies silently. The HttpOnly flag does not prevent all XSS damage, but it eliminates the most common and most immediately impactful consequence: session hijacking. Even applications that believe they have no XSS vulnerabilities benefit from defence-in-depth, because new XSS vectors are regularly discovered in frameworks and libraries. CAPEC-63 (Simple Script Injection) describes the attack pattern this flag directly mitigates.

What Gets Flagged

A cookie sent to the browser without HttpOnly, or with it turned off:

// FLAGGED: no HttpOnly field
http.SetCookie(w, &http.Cookie{Name: "session", Value: sid, Secure: true})

// FLAGGED: literal assigned, then sent
cookie := http.Cookie{Name: "Uid", Value: uid}
http.SetCookie(w, &cookie)

// FLAGGED: explicitly off (net/http, fiber, gin positional, assignment)
http.SetCookie(w, &http.Cookie{Name: "sid", Value: sid, HttpOnly: false})
c.Cookie(&fiber.Cookie{Name: "sid", Value: v, HTTPOnly: false})
c.SetCookie("session", tok, 3600, "/", "", true, false)
c.SetCookie(
    "access_token", token, ttl, "/", domain, true,
    false,
)
ck.HttpOnly = false

// FLAGGED: session options without HttpOnly, or a store whose Options are never set
store.Options = &sessions.Options{Path: "/", MaxAge: 86400, Secure: true}
var store = sessions.NewCookieStore(key)

Not flagged: HttpOnly: true or any expression, deletion cookies (MaxAge: -1, Expires: time.Unix(0, 0)), CSRF/XSRF double-submit cookies (the page’s script must read them), cookies a client sends (req.AddCookie, cookie jars), test files.

Remediation

1. Set HttpOnly: true on every cookie that does not need to be read by JavaScript. The vast majority of session and authentication cookies have no legitimate client-side JavaScript access requirement.

   // SAFE: complete, hardened cookie configuration
   func issueSessionCookie(w http.ResponseWriter, id string, expires time.Time) {
       http.SetCookie(w, &http.Cookie{
           Name:     "session_id",
           Value:    id,
           Path:     "/",
           Expires:  expires,
           Secure:   true,   // HTTPS only
           HttpOnly: true,   // not accessible via document.cookie
           SameSite: http.SameSiteStrictMode,
       })
   }

2. Audit all cookie creation sites, including middleware, authentication libraries, and third-party integrations that may set cookies on your behalf. Centralize cookie creation through a single helper function so the flags are always applied consistently.

3. Apply Secure: true alongside HttpOnly: true to additionally prevent the cookie from being transmitted over unencrypted HTTP connections. Both flags together constitute the baseline for sensitive cookies.

References

• CWE-1004: Sensitive Cookie Without ‘HttpOnly’ Flag
• OWASP Session Management Cheat Sheet
• OWASP HttpOnly
• CAPEC-63: Simple Script Injection
• MITRE ATT&CK T1059.007 – Command and Scripting Interpreter: JavaScript
• Go net/http Cookie documentation

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

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