How do cookies' "secure" flag work to determine whether cookie itself should be included?

e.g. on an HTTP (unencrypted) connection...

  1. user has no cookie yet and tries to log in;
  2. user logs in successfully, server should send "secure" cookie to client;

    • Will the server send cookies to the client via HTTP?
    • Is server the one who is responsible to check the connection and decide to include "secure" cookie?
    • Or are cookies with "secure" flag rejected on HTTP level?

3 Answers 3


The server can ask the browser to set cookies with the secure flag on over HTTP, but the browser should only include them in responses via HTTPS.

But you should never present a request for authentication over HTTP direct responses to authentication requests over HTTP. The former may be tampered with to copy the credentials elsewhere, while the latter can be sniffed.

Mixing and matching HTTP and HTTPS is not a good recipe for a secure site. They should be clearly delimited.

  • so if browser ask server to include cookies with "secure" flag over HTTP connection, the server will have sent cookies with "secure" flag to browser?
    – ted
    Dec 6, 2012 at 14:10
  • in other words, will we have cookie with "secure" flag in our browser when trying that flow with logging in i've described above?
    – ted
    Dec 6, 2012 at 14:14
  • 'so if browser ask server to include cookies' - I don't follow. Cookies are sent from the browser to the server. the browser can't ask the server to send them. After '2' the browser will have the cookie, but it won't send it back to the server in HTTP requests (hence in practice this makes it very hard to determine if they have been authenticated, and as per above, the authentication process is insecure).
    – symcbean
    Dec 6, 2012 at 15:44
  • 2
    The server instructs the client to create a cookie, semantically somewhat different from sending them.
    – symcbean
    Dec 6, 2012 at 15:50
  • 1
    Prove HTTP works? Try it for yourself.
    – symcbean
    Dec 6, 2012 at 20:45

The browser should make sure, that the secure cookie is only sent back to the server for HTTPS requests. Your application should make sure, that secure cookies are only created, if the page was called with HTTPS.

  • so it's the server who decides, to sent or not, "secure" cookie over HTTP conenction back to client? And theoretically we can force server to send back "secure" cookies over HTTP connection?
    – ted
    Dec 6, 2012 at 14:19
  • @ted - Yes that's possible. Your application, or settings (htaccess) have to prevent that. Dec 6, 2012 at 14:23
  • that's great to know. And talking about htaccess where can that be defined? (Sorry for my English)
    – ted
    Dec 6, 2012 at 14:33
  • There are several ways to do a redirect to https, you can either change the config file (if you have the priviledges), or on shared hosting you can change the .htaccess file. You will find a lot of examples to redirect to https. You can redirect the whole site (this is recommended), or you can redirect single pages. Dec 6, 2012 at 14:47
  • The question is not about redirection but to know who is responsible for blocking cookies with secure attribute of being sent from server back to client? (i know that browser is the one to manage that on "client->server" request)
    – ted
    Dec 6, 2012 at 15:37

A cookie is stored on the client, and sent to the server when the "conditions are right" (in particular, cookies are associated with a server, and are sent back to that server only). A cookie marked secure is a cookie which will be sent to the server only when the connection is "secure" (i.e. SSL, aka "HTTPS").

The contents of the cookie are under control of the server: the browser will store in the cookie only what the server tells him to store. Marking a cookie as "secure" makes sense if the contents of the cookie are sensitive in some way (they are confidential, or should not allow external alterations, or, more often, both at the same time). If the cookie contents are sensitive, then they should never be sent over plain HTTP; not when the cookie is sent back to the server (the "secure" flag is about instructing the browser not to commit that specific blunder), but also not when the cookie is initially created.

In short words, if the server is sending, over plain HTTP, a cookie for storage in the client with the "secure" flag, then something is wrong.

In even shorter words: you need site-wide HTTPS. Partial HTTPS is difficult to get right (to some extent, it is mathematically impossible to get right).

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .