When a cookie does not have the Secure-flag set, it will be sent in every request over both HTTP and HTTPS. Even if the web application itself is sent over HTTPS an attacker could still steal the session in use by forcing the user to make an HTTP request and then stealing the session cookie there.
As such, this is a very critical flag to set when using HTTPS, as it can basically be bypassed otherwise.
What can happen?
The attacker could get access to the user’s cookies even when HTTPS is believed to be used. The risk depends on the cookie that lacks this flag.
In the worst case scenario, the cookie will be a session cookie. In such a scenario, the attacker will be able to steal the user’s cookie and then conduct their own requests towards the web server pretending to be the user. The web application will not be able to differ between the authorized user and the attacker, enabling the attacker to do whatever the user can do on the user’s behalf.
The impact this has on cookies other than session tokens totally depends on what kind of cookie it is, and what could happen if an attacker gains access to it. However, as long as the whole web application is sent over HTTPS there are no benefits in not setting the secure-flag.
Code example
This is the most common way to set cookies in PHP, empty variables will hold their default value.
setcookie($name, $value, $expire, $path, $domain, $secure, $httponly);
A insecure way could look like this:
setcookie("nameOfCookie", "valueOfCookie");The easiest way to set a cookie with the secure flag would therefore be:
setcookie("myCookie", "value", "", "", "", true, "");Remediation
Please see the OWASP page for remediation. If anything is unclear, reach out to [email protected] and we will help out the best we can.
Please keep in mind that modern browsers will not accept a secure flag set over HTTP. The page must be transmitted over HTTPS for the directive to work properly.