Earlier, someone proposed on the GH issues tracker that Rails default all cookies to HttpOnly[1]. Rails already makes the session cookie HttpOnly, but given a general to keep Rails secure-by-default, it would probably be best if all cookies defaulted to HttpOnly. This would be a compatibility-breaking change, but it wouldn’t be difficult to add a configuration option that can be defaulted to false for existing Rails apps that are upgraded.
I’m more than happy to write the code for this change, but wanted to discuss it here first to see if anyone objects strongly. Josh Peek had concerns with backwards compatibility, but I think my proposal above for a configuration option should satisfy them. Anyone care to weigh in?
I would argue that if you have some information that can’t be hijacked and even parsed on javascript (httponly cookies can’t be read on javascript at all), why would you use cookies instead of the rails session?
I’ve had to resort to some pretty weird cookie stuff when passing data between a Rails app and non-Rails applications. The session is handy, but parsing it anywhere but in Rails is difficult and updating it outside of Rails is more difficult.
I can’t be sure but using cookies for that sounds the wrong solution for me, you have better options like a shared database, a redis instance may work.
You’ll need to use a cookie to share a session identifier (I would use a uuid) between the applications but reducing it to just one cookie may mitigate the need to mark all shared cookies as http only, but I don’t know your environment, so please don’t take this a recommendation
About rails, I would be concerned to backwards compatibility too, but we need to have access to both options (httponly and not httponly).
Something like cookies.secure[:key] = ‘value’ and cookies[:key] = ‘value’ may work but it won’t be secure as default.
If we are choosing for security first, we may have cookies.insecure[:key] = ‘value’ or something like that.
In that case, even that shared cookie should likely be HttpOnly anyway.
I’m not quite following why anyone would really oppose such a change here — Rails needs to maintain a strong secure-by-default stance, and every case where developers have to opt-in to security is a case where many developers will not. As long as there’s a flag that’s set to the current behavior for existing projects, and defaults to secure behavior for new projects, there shouldn’t be any backward-compatibility concerns.
If you need to access a cookie in JS, set it in JS or disable HttpOnly for that specific cookie. If a developer doesn’t upfront anticipate it being used in JS, then it shouldn’t be allowed to be accessed from there.
Is this proposal dead? I would like to see this as well. It seems like a default worth having, and an optional way to turn it off solves the backwards compatibility problem.
