Recently, while checking out Mozilla Observatory I learned about the
Set-Cookie directive. If you’re not familiar with it, here’s an explanation from MDN…
The “HttpOnly” name is a bit confusing and is sometimes misinterpreted as having something do to with HTTP vs HTTPS. However, that is not the case. The idea is that the cookie is made available to the server as part of the HTTP request (“HTTP only”). However, the browser has no access to it.
This provides a layer of security against XSS as, even if an attacker is able to get malicious script to execute on a web page, the attacker won’t be able to access precious cookies, which are often the only key needed to compromise a user (or admin) account.
This got me interested in investigating how Magento manages that flag. I decided to dig in to get a better understanding. Here, I’ll documented my findings…
Before looking at how Magento manages this directive, it’s worthwhile to look at how it is managed by PHP.
setcookie function allows the user to manage the
HttpOnly flag through the
httponly parameter, the 7th and final parameter.
setcookie($name, $value, $expire, $path, $domain, $secure, $httponly)
If set to
Set-Cookie response header will include the
By default, PHP sets
$httponly to false.
In the Magento admin panel there is a setting in the “Cookies” group called “Use HTTP Only”. If set to “Yes”, all cookies set by the framework will include the
In Magento 2 this setting is available under Stores > Configuration > General > Web > Default Cookie Settings…
In Magento 1 it’s available under System > Configuration > General > Web > Session Cookie Management…
The default setting is “Yes” in both Magento 1 and Magento 2.
Http-Only cookies are not accessible to the browser, they cannot be stolen by XSS. As such you should always leave this setting on! In Magento 2 the following comment was even added to this setting…
Warning: Do not set to “No”. User security could be compromised.
I’m not sure why Magento doesn’t just remove this setting entirely since they’ve so strongly discouraged changing it
If you have any questions or comments, feel free to drop a note below, or, as always, you can reach me on Twitter as well.
Did you enjoy this blog post?
If so, please consider checking out my side project Domain Clamp. It's a SaaS which monitors domains and SSL certificates and sends notifications before anything expires. If you work at an agency, then you're probably not the registrant for your client's domains or the SSL certificate owner. This means you won't get expiration notifications. You don't want a client's domain or SSL certificate to expire under your watch. Believe me, I've been there.
Domain Clamp solves this problem by letting you monitor the SSL certificate and registration for any domain you'd damn please. Free accounts are available so please head on over »