Assuming a site is using all HTTPS all the time (LB redirects port 80 to 443), is there any reason not to force every cookie set by the application to use BOTH secure AND httponly?

Currently, for example, a PCI scan will only flag the jsessionid as not using the secure attribute, but tomorrow it could be the other one, so I'm trying to get ahead of it.

  • 5
    A lot of the time you want JS to be able to read to cookie to pass info back and forth to the server without additional http connections like ajax. – dandavis May 24 at 18:25
  • this can be achieved without using the document.cookie API too. HttpOnly provides protection against reading of cookies against XSS attacks. It should be used if possible. – entropy May 24 at 18:51
  • 1
    The obvious reason is that it isn't httponly. Like when you have JavaScript that reads from cookies. – Anthony May 25 at 6:15
up vote 35 down vote accepted

Yes, there are cases where you don't want HTTP ONLY or SECURE.

For HTTP Only, you might want javascript to interact with the cookie. Maybe you track page state in a cookie, write to the cookie with JS, and read from JS. Also I often see CSRF implemented with an not-http-only cookie.

For the Secure cookie, I wouldn't expect any cookies to ever not have the secure attribute except for these two cases:

  1. development environments often don't have or need to have TLS certs (though maybe they should)
  2. to track activity that originated on http. You might even use your load balancer to set an insecure cookie before it sends back the redirect. Then your application analytics can track which URLs came in as HTTP.

In practice, if you're running an https site, always set the secure cookie, and if you don't know JS requirements, always error on the side with HTTPONLY set.

UPDATE TO ADDRESS COMMENTS

A lot of talk about whether you should or shouldn't use TLS in production. Posted the question here:

Should I develop with TLS on or off?

  • 14
    development environments often don't have or need to have TLS certs <-- but should. They can use a self-signed certificate or even one made with Lets Encrypt. – Ismael Miguel May 25 at 8:13
  • 19
    @IsmaelMiguel: There is literally no need to bother with that in a local development environment and it prohibits examining data on the wire. "It should" is false. However yes you should do a test before deploying. – Lightness Races in Orbit May 25 at 11:50
  • 13
    @IsmaelMiguel You can't Let's Encrypt a local, non-Internet-addressable developer site, and self-signed certs are usually problematic, especially in organizations that also have security restrictions to prevent accessing sites with certificate issues (since self-signed certs can't be verified, the site itself would be inaccessible for anyone to test). – phyrfox May 25 at 12:01
  • 8
    @IsmaelMiguel Yes, but that's my point. If I don't want to expose my site to the Internet, and I'm in some sort of enterprise, restricted network, then your advice is at best useless and possibly even harmful (e.g. you enable TLS and lose access to your management console). Of course you should prefer security over not, but a blanket statement like "but should" could cause someone somewhere grief. At minimum, it should be a qualified/conditional statement. – phyrfox May 25 at 12:26
  • 3
    Note also that the layer that does SSL termination does not need to be the layer that actually serves the request. Decoupling those layers can greatly ease development pains. Ideally, of course, TLS termination is done on the same machine as the application logic, or at least within the same trusted network segment. Otherwise you need a new TLS session, and now you have two problems. – Kevin May 26 at 3:55

Regarding httponly you are essentially asking if they are use cases where a cookie needs to be read or set by Javascript. Typically some settings of the user interface (choice of language ...) are preserved this way which would break if the cookie is httponly.

As for secure: since according to your description the site is using https all the time it does not harm to have all cookies secure.

Secure Flag

Considering that the application is running over HTTPS i.e. LB redirects all port 80 traffic to 443, it is still required to enable the secure flag in light of the following scenario.

  1. Assume that there is a developmental glitch as a result of which a hyperlink contains the HTTP (eg. http://example.com/some_page.php) link instead of the HTTPS (eg. https://example.com/some_page.php) link.
  2. The browser requests the web resource over HTTP and sends the cookie along with it due to the absence of the secure flag.
  3. The request reaches the LB which redirects the traffic to port 443 i.e. over HTTPS.
  4. The browser re-initiates the request but this time over HTTPS with the cookie value.

Hence, although the LB is configured to redirect port 80 insecure traffic to port 443 secure traffic, a successful MiTM attack could take place at step 2 resulting in the impersonation of a user by stealing the sensitive cookies. Moreover, verifying that the hyperlinks and redirects are properly coded is a comparatively more strenuous activity than enabling the secure flag on sensitive cookies. To conclude, although a redirect is set-up at the LB Level there could be possible scenarios where a fruitful MiTM could be executed due to the absence of the secure flag.

httponly Flag

This is a flag whose significance stays independent of the Transport Layer Security (SSL/TLS). The httponly flag is used to prevent javascript from accessing sensitive cookies like the session cookies in the event of a successful Cross-Site Scripting (XSS) Attack. When the httponly flag is not set on the cookie value, the malicious javascript injected into the application due to an application level flaw could end up sabotaging the confidentiality, integrity and availability of user accounts by reading session cookies and sending them to remote servers for instance, thereby successfully impersonating a legitimate user. Hence the httponly flag should always be set on all cookies or at least the sensitive ones.

  • If the site in question is a SPA, then you typically do not want httponly, but you'll also need to use CSP and other security measures to prevent rogue scripts from stealing session data. – phyrfox May 25 at 12:07
  • I totally agree @phyrfox there is always the possibility of using CSP to prevent rogue scripts from stealing session data. But lets also consider the fact that httponly has a greater browser support compared to CSPs. Source: browserscope.org/?category=security – Tony Thomas May 25 at 12:53

I'll give you a practical example of a non httponly cookie.

When a visitor comes to my site there are two cookies shoved down his/her throat.

phpsession -> secure httponly samesite:lax
cookie_law -> secure samesite:lax

The cookie_law contains a base64 encoded json encoded cookie object that stores the cookie settings.

My javascript reads those cookies to determine to load analytics, adwords dependent on permission or status.
My javascript also uses that cookie to make the cookie settings editor work.

If I set the httponly flag on the cookies the javascript can't read it. And I can't use php to determine load status when rendering the scripts because of multiple layers of caching. Thats why I chose to leave the httponly from that cookie.

The javascript needs access to be able to read it.

http-only: Sometimes user preferences (font-size, theme, language, ...) are set and acted upon client-side. This is the most common case for needing them not set http-only.

secure: As the site/app insists on HTTPS there is no reason not to use the secure flag. If the site/app needs to offer access via HTTP and you need details to pass between encrypted/no contexts (perhaps the user's display preferences again) then you need to leave this off.

While it may seem to not matter as you currently force HTTPS access, you should allow for failures in that: your app may be redeployed with incorrect settings, or your users may find themselves subject to a MItM (either something malicious or a badly configured proxy) that has a similar effect and with this flag set things fail safe (from a security point of view) by stopping working rather than working insecurely.

General: As they are security measures, however minor they may seem, always set both unless you have specific reason not to, rather than ever defaulting to leaving them off unless you think they are needed.

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.