: What are the problems of httponly and secure cookies? We would like to set: all our cookies (session id, etc.) as "httponly" all security (session token, "remember me", etc.) cookies as "secure"

@Murray432

The httponly flag just indicates that a browser should not allow to alter the cookie with javascript. This is only a browser thing and there is no sane reason, why a search engine should handle such pages differently. Whenever you don't need to access the cookie per javascript (probably in most cases), you should use this flag. Not using it is just lazyness in my opinion.

The Secure flag only makes sense on HTTPS sites of course. The well known non-HTTPS sites you mentioned, cannot use this flag, because the browser would not send back the cookie. Again this is a browser thing, a search engine could easily send back this secure cookie through HTTPS, though the content that requires a secure session is normally not what you want to find in a search engine. So the question is more, whether content of the page depends on the secure cookie or not.

Vote Up Vote Down

@Candy875

It really depends on the data you are storing. If your site doesn't use an SSL cert this is easy. Everything would go in httpOnly cookies or session variables. You would decide that based on whether the data you were storing is sensitive. If it's storing the user background color choice then httpOnly is really always fine. It it's storing something which could potentially be dangerous in the wrong hands then you want to use a session. The session ID itself doesn't need to be encrypted though.

The problem with secure cookies is that they can be cracked with enough time. For this reason they are never considered good for high security. That being said, they do offer a sort of medium security that when properly used can save your server resources. If you have a reasonably well powered server then I would suggest sticking to session variables. But in the right situation a secure cookie is useful. If your app needs a lot of client side data (from a ajax DB front end for example) then storing that data in a secure cookie which expires at the end of the session may be a great idea.

A good rule of thumb is that if the page needs to use SSL then so should the cookies. The cookies are no less secure than the page. That goes for httpOnly and secure cookies. Also, secure cookies are a greater security risk only when they don't expire because that give a potential hacker longer to find them.

UPDATE: Negligence seems likely but it could also just be because the server is overburdened and it'd be too much overhead to run SSL for all of that. This seems unlikely though because modern CPUs have dramatically sped up SSL encryption. I do think that there is a limitation in that if the user is accessing your site using http then secure cookies will not be visible (or at least wont always work in all browsers). I've had trouble with that in the past but others seem to think that it works fine. Personally, I use SSL on nearly every site I run where someone has to log in; just to be safe. It probably isn't the greenest thing to do but makes me sleep better. I'd say that as long as you can do it you should use SSL and secure cookies and always use httpOnly unless you can't.

And as another poster has already mentioned search bots typically ignore cookies. You can check for GOOGLEBOT in the request header to display content to Google as if it is logged in (but that sort of defeats the point of hiding content until someone logs in).

Vote Up Vote Down

@Si4351233

There aren't any real problems adding the httpOnly flag when setting a cookie. It only works if a browser supports the flag.

A list of browsers which support it can be found at www.owasp.org/index.php/HTTPOnly#Browsers_Supporting_HttpOnly
Googlebot has nothing to do with cookies

It's not negligence if a site doesn't use a secure cookie, at least most of the time. There are many reasons a cookie would be used over a session and or a session used rather than a cookie.

Vote Up Vote Down