Any reason NOT to set all cookies to use httponly and secure

  • 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.

    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.

    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.

    The obvious reason is that it isn't httponly. Like when you have JavaScript that reads from cookies.

  • Jonathan

    Jonathan Correct answer

    3 years ago

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

    If you need javascript to see the cookie value, then you remove the HTTP-Only flag. A couple cases - some sites track the page state in a cookie using javascript to read and write the cookie value. CSRF mitigations often rely on the server sending a value in a cookie, and expect javascript to read that value.

    The Secure flag is more important. If we expect all sites to run over https, and only https, then the only http part is a redirect to https. You never want your cookie sent in the clear. Well, almost never. Here are two cases where you might:

    1. development environments often don't have, or don't 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. Your load balancer can track which sessions came in as http.

    In practice, if you're running an https site, always set the secure cookie, and always error on the safe side by setting HTTPONLY, unless you know your javascript requires cookie access.

    UPDATE - TLS in Development

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

    Should I develop with TLS on or off?

    `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.

    Oh, another point to use https: how can you know your website is working properly with https if you dont test it with https before deplying?

    @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.

    @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 That's a specific instance of a development environment

    @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 Exactly! I said *should*, not *must*! One is a suggestion, the other is a demand. Basically, you should use a certificate and enable TLS, but you aren't obligated to. It isnt mandatory. You still should find a way, if viable.

    and this is the reason data breaches, defacings and all kinds of mischief are made possible and happen all the time. Your development environment should be as close as possible to your deployment environment, otherwise you will invariably start amassing technical debt or end up developing in a way that will be difficult or impossible to secure, or worse.

    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.

    @LightnessRacesinOrbit But this question shows the dire need of developing in TLS! OP exactly followed your path: system is developed as open, nobody has experience how `secure` works, and after devs finish, TLS is slapped on top of it like a magic talisman. The exact opposite is true: "There is literally no need to bother with open connection in a local development environment except cases of examining wire". This gives everyone understanding of how TLS works and how it's different from open connection. BTW, you can examine wire with MitM, that also teaches certpinning. Security first.

    Just a nitpick: having SSL on your dev/internal environment *IS* a good practice, and does *NOT* prevent you from viewing the traffic on the wire; that's what a simple SSL proxy is for.

    @AngeloSchilling even chrome dev tools will show you a lot of what you need in the network tab.

License under CC-BY-SA with attribution

Content dated before 7/24/2021 11:53 AM

Tags used