Secure Cookies

The `Secure` cookie attribute restricts a cookie so that browsers send it only over HTTPS connections. It helps prevent cookie values from being exposed through unencrypted HTTP traffic.

A cookie set with the `Secure` attribute is intended to travel only over secure HTTPS connections. If a request uses plain HTTP, the browser does not include that cookie in the request.

For frontend security, `Secure` is especially important for cookies containing session identifiers or other sensitive values. HTTPS protects the cookie while it travels between the browser and server, while `Secure` prevents the cookie from being sent over an unencrypted connection.

`Secure` does not make a cookie inaccessible to JavaScript. The separate `HttpOnly` attribute prevents JavaScript from reading the cookie through APIs such as `document.cookie`. A cookie can use both attributes together.

The `Secure` attribute also does not replace HTTPS configuration, authentication controls, or other cookie protections. Common related attributes include `HttpOnly`, `SameSite`, `Domain`, and `Path`.

Key points

• `Secure` cookies are sent only over HTTPS connections.
• `Secure` protects transmission but does not prevent JavaScript access.
• `HttpOnly` is the attribute that blocks JavaScript access to a cookie.
• Sensitive session cookies commonly use `Secure` together with `HttpOnly` and an appropriate `SameSite` policy.

Interview questions

What does the `Secure` cookie attribute do?

The `Secure` attribute tells the browser to send the cookie only with HTTPS requests. This prevents the cookie from being transmitted over ordinary unencrypted HTTP. It is commonly used for cookies that carry authentication or session information.

Does `Secure` prevent XSS from stealing a cookie?

Not by itself. `Secure` controls network transmission, not JavaScript access. If a cookie is readable by JavaScript, an XSS vulnerability may allow its value to be accessed. The `HttpOnly` attribute is used to prevent JavaScript from reading the cookie.

Why would an authentication cookie commonly use both `Secure` and `HttpOnly`?

`Secure` limits the cookie to HTTPS requests, protecting it from transmission over unencrypted HTTP. `HttpOnly` prevents page scripts from reading the cookie through browser scripting APIs. Together they address two different exposure paths: network transport and script access. They are still not a complete security strategy because attributes such as `SameSite` and server-side session protections may also matter.

Can a `Secure` cookie be set or used over HTTP?

A `Secure` cookie is intended to be sent only over secure connections. A browser therefore does not include it in ordinary HTTP requests. Setting and using secure cookies should be designed around HTTPS, with development environments configured appropriately rather than relying on insecure transport.

How would you design a secure session cookie for a frontend application?

I would normally use a server-set cookie with `Secure` and `HttpOnly`, plus an appropriate `SameSite` policy for the application's cross-site requirements. I would serve the application and authentication endpoints over HTTPS. I would also consider session expiration, rotation, CSRF defenses where applicable, and server-side invalidation. The exact `SameSite` choice depends on the application's architecture and whether legitimate cross-site requests are required.