CWE-614 is the omission of the Secure attribute on a sensitive cookie in an HTTPS session. It is a small flag with a clear effect, and it affects any web application that sets cookies.
How it happens
A site serves its pages over HTTPS and sets a session cookie, but the Set-Cookie header lacks Secure.
Set-Cookie: sessionid=abc123; Path=/; HttpOnly
Without the flag, the browser is free to send the cookie on any request to the domain, including an http one. A user who clicks an old http link, or is nudged onto one by someone on the same network, sends the session cookie in plaintext.
The same mistake has been made in libraries as well as applications. MITRE's observed examples include:
- CVE-2024-47833: a Python library for ML and data science that did not use the Secure flag for session cookies.
- CVE-2004-0462: a product that did not set the Secure attribute for sensitive cookies in HTTPS sessions, so the user agent could send them in plaintext over an HTTP session.
- CVE-2008-3663 and CVE-2008-3662: products that did not set the secure flag for the session cookie, making it easier for remote attackers to capture it from http requests.
What an attacker gains
The consequence in the record is confidentiality. The cookie can travel in plaintext over HTTP, where anyone positioned on the network path can read it. A stolen session cookie is typically as good as a password for the life of the session.
How to find it
Static analysis (SAST) can find some instances by flagging cookie creation without the flag. You can also check in under a minute:
- Open your browser dev tools, go to the Application or Storage tab, and look at your cookies.
- Check the Secure column for the session cookie and any other sensitive one.
- Or run
curl -sI https://your.site/loginand read theSet-Cookielines.
If your app depends on a framework or library that sets the cookie for you, look at its version and configuration too. A free scan at gold.safeguard.sh/scan lists the dependencies in a manifest in your browser, with no login and up to 100 dependencies.
Click through it at your own pace, or open it full screen.
How to fix it
MITRE's mitigation: always set the secure attribute when the cookie should be sent via HTTPS only.
# Flask
app.config.update(
SESSION_COOKIE_SECURE=True,
SESSION_COOKIE_HTTPONLY=True,
SESSION_COOKIE_SAMESITE="Lax",
)
// Express
res.cookie("sessionid", value, { secure: true, httpOnly: true, sameSite: "lax" });
Related steps that make the flag effective:
- Serve the whole site over HTTPS and redirect http to https.
- Add an HTTP Strict Transport Security header so browsers stop trying http at all.
- Apply the flag to every sensitive cookie, not only the session ID.
Quick check
Does HTTPS alone protect the cookie?
No. Without the Secure attribute the browser may still send the cookie over an http request to the same domain.
How can you check a cookie in seconds?
Open dev tools and look at the Secure column for the cookie, or read the Set-Cookie header with curl.
