Secure Cookies
The Secure attribute on a cookie instructs the browser to only include the cookie in requests sent over HTTPS encrypted connections, preventing the cookie from being transmitted in plaintext over HTTP.
Understanding Secure Cookies
Without the Secure flag, cookies are sent with both HTTP and HTTPS requests. If a user accesses your site over HTTP — even accidentally, through a bookmark or a link — the session cookie is transmitted in plaintext, visible to anyone monitoring the network. On public WiFi, this means any session cookie without the Secure flag can be captured by a passive network observer.
The Secure flag is a simple but essential defense. When set, the browser silently omits the cookie from any HTTP request. Combined with HSTS (which redirects HTTP to HTTPS), the Secure flag ensures session cookies are never exposed in transit. Even if the user types http:// in the address bar, HSTS redirects to HTTPS before any request is sent, and the Secure flag provides a fallback for the rare case where an HTTP request does go out.
Since 2017, major browsers treat cookies without the Secure flag as increasingly suspicious. Chrome has moved toward requiring the Secure flag for SameSite=None cookies. Future browser versions may further restrict non-Secure cookies. Setting the Secure flag is essentially a requirement for modern web applications.
The Secure flag is set in the Set-Cookie header: Set-Cookie: token=abc; Secure; HttpOnly; SameSite=Lax. It cannot be set by client-side JavaScript on cookies created via document.cookie on HTTP pages (since Chrome 52, the Secure flag is required for SameSite=None cookies and is generally enforced for cookies set over HTTPS).
Why This Matters for Vibe-Coded Apps
The Secure cookie flag is one of the safest security improvements for any vibe-coded app running on HTTPS. It has zero functional side effects if your site is HTTPS-only (which it should be). AI-generated authentication code sometimes omits the Secure flag when setting cookies, especially in development where HTTP is common.
When deploying your vibe-coded app, verify that all cookies set by your server include the Secure flag. In Node.js/Express, this means setting secure: true in the cookie options. Most hosting platforms (Render, Vercel, Cloudflare) serve over HTTPS by default, making the Secure flag both safe and necessary.
Real-World Examples
Firesheep WiFi Attack Demonstration
The Firesheep tool specifically targeted session cookies without the Secure flag on public WiFi. It captured HTTP cookies for sites like Facebook and Twitter, allowing instant session hijacking. The widespread deployment of HTTPS and Secure cookies was partly driven by this demonstration.
Browser Cookie Security Evolution
Chrome, Firefox, and Safari have progressively tightened cookie security. Chrome 80 enforced SameSite=Lax by default and required the Secure flag for SameSite=None cookies. These changes pushed millions of websites to adopt the Secure flag, significantly reducing the cookie exposure surface across the web.
PCI DSS Cookie Requirements
The Payment Card Industry Data Security Standard requires that all session cookies for cardholder data environments use the Secure flag. Compliance audits specifically check for this attribute on authentication and session cookies, making it a regulatory requirement for any site handling payment information.
Frequently Asked Questions
Can I use Secure cookies during local development on HTTP?
Secure cookies cannot be set or sent over plain HTTP connections, which causes issues during local development on http://localhost. Modern browsers make an exception for localhost: Chrome and Firefox allow Secure cookies on http://localhost. However, for the most consistent experience, use HTTPS in local development with a self-signed certificate via tools like mkcert. Alternatively, conditionally set the Secure flag based on the environment.
Is the Secure flag redundant if I use HSTS?
Not entirely. HSTS ensures the browser always connects over HTTPS, which means cookies will always be sent over HTTPS. However, HSTS relies on the browser having visited the site before (unless preloaded). On the very first visit, if the browser somehow reaches HTTP before the HSTS redirect, a non-Secure cookie could be exposed. The Secure flag provides a belt-and-suspenders defense for that edge case and is considered best practice alongside HSTS.
What happens to Secure cookies on an HTTP page?
Secure cookies are silently excluded from HTTP requests. The browser does not send them, does not generate an error, and does not inform the page that cookies were withheld. This means if your server sets a Secure session cookie and the user somehow accesses your site over HTTP, they appear to be logged out because the session cookie is not sent. This is the intended behavior — it prevents accidental exposure.
Should all cookies have the Secure flag?
On any site served over HTTPS (which should be all production sites), yes. There is no reason for a cookie to be sent over HTTP when the site only serves HTTPS. Session cookies, preference cookies, analytics cookies, and any other cookies should all have the Secure flag. The only exception is during local development on plain HTTP, and even then, most browsers support Secure cookies on localhost.
Is Your App Protected?
VAS automatically scans for vulnerabilities related to secure cookies and provides detailed remediation guidance. Our scanner targets issues common in AI-generated applications.
Scans from $5, results in minutes. Get actionable fixes tailored to your stack.
Get Starter Scan