How does cookie "Secure" flag work?

Question

I know that a cookie with secure flag won't be sent via an unencrypted connection. I wonder how this works in-depth.

Who is responsible for determining whether the cookie will be sent or not?

Note: this "Secure" flag is only just _one_ layer in defense in depth - an attacker is _still_ able to _write_ to a "Secure" cookie if they can MITM, and this has the potential to lead to a session fixation attack - [this related thread](https://stackoverflow.com/questions/72641144/how-is-cookie-susceptible-to-mim-attack-when-it-is-using-secure-attribute-over-h/) asked how and I provided an in-depth answer on how this is done, plus how this may be mitigated (HSTS can work, but also a specific name prefix can be used together to fully mitigate this). — metatoaster, Jun 13 '23 at 10:30

score 101 · Accepted Answer · edited Oct 07 '21 at 05:46

101

The client sets this only for encrypted connections and this is defined in RFC 6265:

The Secure attribute limits the scope of the cookie to "secure" channels (where "secure" is defined by the user agent). When a cookie has the Secure attribute, the user agent will include the cookie in an HTTP request only if the request is transmitted over a secure channel (typically HTTP over Transport Layer Security (TLS) [RFC2818]).

Although seemingly useful for protecting cookies from active network attackers, the Secure attribute protects only the cookie's confidentiality. An active network attacker can overwrite Secure cookies from an insecure channel, disrupting their integrity (see Section 8.6 for more details).

edited Oct 07 '21 at 05:46

Community

1
1

answered Dec 05 '12 at 18:43

Cratylus

52,998
69
209
339

4

in case the client-side doesn't have cookie yet and they should be sent from server-side(e.g. logging in) will server-side be the one to decide to include cookie in response? – ted Dec 05 '12 at 21:57
3

Server initially sets cookies via "Set-Cookie headers" – Ivan May 25 '16 at 00:54

score 56 · Answer 2 · edited Mar 13 '18 at 20:46

56

Just another word on the subject:

Omitting secure because your website example.com is fully https is not enough.

If your user is explicitly reaching http://example.com, they will be redirected to https://example.com but that's too late already; the first request contained the cookie.

edited Mar 13 '18 at 20:46

ruffin

16,507
9
88
138

answered Nov 18 '16 at 16:55

Alain Tiemblo

36,099
17
121
153

6

I know this is old, but HSTS preload helps this situation by preventing this problem from occurring frequently. Its still not 100% fix but its just another thing to consider if you really want to avoid secure cookie. – Mr. MonoChrome Nov 28 '16 at 23:49
6

@Mr.MonoChrome Why would you want to avoid secure cookie? – MEMark Apr 21 '17 at 13:30
@Mr.MonoChrome though some older or lower spec browsers, i believe, don't even support HSTS – oldboy Sep 03 '17 at 03:31
1

Good point. For .NET applications it is better to do the redirect in IIS (or web.config) rather than programmatically (for example globals.asax) – piris Sep 28 '17 at 15:23
So if you weren't redirecting from http to https, and only serving on https, you wouldn't need `secure` ? – braks Dec 20 '17 at 11:05
Is it necessary to worry about this if you have an htaccess rule being used to force HTTPS? – DaveTheMinion Jun 30 '18 at 20:54
1

@braks sure, but accessing your website on port 80 would give a connection refused, and browsers/users don't expect that. – Alain Tiemblo Jul 01 '18 at 07:36
1

@DavidB yes, for the very reason i given above. – Alain Tiemblo Jul 01 '18 at 07:36
Okay. I thought your reason was limited to connections redirected using HTML redirects. – DaveTheMinion Jul 01 '18 at 13:47
@AlainTiemblo The URL wasn't public facing, so this worked out fine – braks Jul 04 '18 at 01:42

How does cookie "Secure" flag work?

2 Answers2

Linked