Cookie warnings: Cookie prefix absent from IPS4 set-cookie header

[The Old Man]

TL;DR - For best practice, please can you enable the secure cookie prefix in http headers for https enabled IPS4 sites?
 

Whilst looking into unrelated http caching headers, I've become aware that https://securityheaders.com/ is reporting the following message:

Quote

There is no Cookie Prefix on this cookie. This is not a SameSite Cookie.

set-cookie	ips4_IPSSessionFront=fjgyudsrydugilgkufgudiyfulfykdjgd; path=/; secure; HttpOnly

I tested all my IPS4 sites and the IPS website here (quick link below) and it happens on them all, so I'm thinking it's IPS4 rather than my Apache server:

https://securityheaders.com/?q=https%3A%2F%2Finvisioncommunity.com%2Fforums%2F&hide=on&followRedirects=on

 

Quote

There are 2 requirements for cookies that have the __Secure- prefix:

Set with a "Secure" attribute

Set from a URI whose "scheme" is considered "secure" by the user agent.

Although I have https enabled which meets the second requirement, the cookie isn't treated as same site because the cookie isn't configured with the necessary prefix. I imagine it's a fairly quick fix so that it outputs something like this on an https enabled site:

set-cookie	__Secure-ips4_IPSSessionFront=fjgyudsrydugilgkufgudiyfulfykdjgd; path=/; secure; HttpOnly

Thanks for reading.

[Randy Calvert]

I'm not sure how much of a big deal this is...  Even big bank sites like Chase don't set it for the login pages for their online banking site.  

And the same for Citibank...

If there was anything of actual real value or super sensitive, it might make sense to set the cookie as secure...  but that cookie is not exposing anything critical.

While I understand that people love running tools to scan their sites and it's a good thing to do...  it's more important to understand the results and what they're recommending.  These tools don't necessarily know the site or why something is done the way it is.  In many cases there may be other compensating controls or not matter based on how it is used.  There have even been cases where the result is an overall false positive.  🙂 

Edited June 17, 2022 by Randy Calvert

[Matt]

Automated tools are very useful in helping you ensure your site is compliant and secure but sometimes they mark you down for things that just aren't a problem in the real world.

We work with some of the world's biggest brands who often bring in third party security specialists and not once have we been asked to use this prefix.

If you redirect your site from http to https then the impact is minimal. The blog linked above was written in 2017 when SSL was very much optional for most of the web, but now browsers really enforce SSL so it's less of a problem. The author and MDN note that not all browsers (including Safari and Firefox) support the prefix and will serve the cookie anyway making it a little pointless outside of an internal network where you can enforce which browsers can be used.

[The Old Man]

Thanks both for sharing your thoughts on this.