=== on 26 Aug 2015, 19:34:37 Ann Campbell wrote:
\[~linda.martin] I recognize that this one may be a bear to implement since the flag could be set either in php.ini _or_ in code. If possible I'd like to see it work like this:

----
if ( HTTPOnly in php.ini) {
  no issue
} else if (set(cookie) && ! cookie.has(HTTPOnly)){
  issue
}
----

Also, I didn't provide any code samples because I wasn't sure whether you'd want to show code or configuration

=== on 15 Sep 2015, 21:16:36 Evgeny Mandrikov wrote:
IMO from an implementation point of view this RSPEC is underspecified, so removing targeting for ``{cpp}`` for now.

=== on 17 Sep 2015, 15:19:48 Ann Campbell wrote:
\[~evgeny.mandrikov] what more are you looking for?

=== on 17 Sep 2015, 16:07:55 Evgeny Mandrikov wrote:
\[~ann.campbell.2] what this RSPEC supposed to find in {cpp} code

but the reason of removal targeting: currently there are too much (for my taste) issues in backlog targeting {cpp} and about which I have no idea of how implementation can look like, which complicates work with this backlog

=== on 13 Nov 2015, 15:06:03 Linda Martin wrote:
\[~ann.campbell.2] sorry for the delay, looks good that way and maybe both configuration and code could be given as they could both trigger issues.

=== on 17 Nov 2015, 14:45:56 Ann Campbell wrote:
Code samples added

=== on 18 Oct 2016, 17:09:17 Pierre-Yves Nicolas wrote:
My understanding is that cookies can be created with http://php.net/manual/en/function.setcookie.php[setcookie], but PHP also manages directly the "session cookie": the settings of the session cookie can be modified with http://php.net/manual/en/session.configuration.php#ini.session.cookie-httponly[session.cookie_httponly] in php.ini or inside PHP code with http://php.net/manual/en/function.session-set-cookie-params.php[session_set_cookie_params]. The rule should probably check all 3 usages.

=== on 2 Dec 2018, 22:54:25 Lars Svensson wrote:
There could be many legitimate reasons why an application needs script access to a cookie. To mitigate CSRF is just one example. Another example could be for user interface settings that are persisted across page refreshes.


(Also, when mitigating CSRF, there are multiple ways you can go. Using a cookie is just one of them. And the cookie name is framework specific - even though it happens to be called "XSRF-TOKEN" in some popular frameworks, there are many examples of other names used in the field)


IMO, it is only relevant to set the HttpOnly flag for security-sensitive cookies. Since it could be difficult to detect whether a cookie is used in a security context, perhaps this rule should be changed into a Security Hotspot instead.


I also propose to lower the default severity as a missing HttpOnly flag is not an exploitable vulnerability in itself, even if the cookie is used in a security context. It is only together with for example a Cross Site Scripting vulnerability that it is exploitable.

=== on 18 Dec 2018, 10:22:50 Alexandre Gigleux wrote:
My take on this one is that I guess that the FP Rate is below 10% and so majority of the time, HttpOnly should be set. Yes, we will have FPs on CSRF Cookies and in that case, I would expect users to raise the point on \https://community.sonarsource.com to start a discussion. I propose to keep it like this for the moment and see users' reactions.

=== on 9 Oct 2019, 17:50:01 Ann Campbell wrote:
\[~eric.therond] generally speaking you want to use _either_ "this" or "here" in the message:


* Make sure creating a cookie without the "HttpOnly" flag is safe here.
* Make sure creating this cookie without the "HttpOnly" flag is safe.

IMO the 2nd version is nicer.