Potential false positive with Cookie HttpOnly flag


when scanning a WikiJS installation with login at the root URL, OpenVAS reports a Missing httpOnly Cookie Attribute. The details report the following:

Detection Result

The cookies:

Set-Cookie: loginRedirect=%2F; Max-Age=900; Path=/;  HttpOnly; Secure; SameSite=***replaced***;; Expires=Sat, 07 Jan 2023 09:33:42 GMT

are missing the "httpOnly" attribute.

The issue here is the regex expression:

if( cookie !~ ";[ ]?[H|h]ttp[O|o]nly?[^a-zA-Z0-9_-]?" ) {

which matches only one empty space character. In my example there are 2 spaces, which is probably not good but also still valid AFAICT.

Thanks a lot for raising your concerns.

If i’m interpreting / understanding https://www.rfc-editor.org/rfc/rfc6265#section-4.1.1 correctly there should be exactly one space (SP) between a ; and the next cookie value:

set-cookie-string = cookie-pair *( ";" SP cookie-av )

This would even mean that a regex like e.g. the following should be used:

if( cookie !~ "; [H|h]ttp[O|o]nly?[^a-zA-Z0-9_-]?" ) {

Do you have by any chance a reference how browsers are handling such things (e.g. accepting none or more then two spaces?).

If something like this exists and shows that more then one space is also acceptable the check / regex could be updated accordingly to handle such non-standard strings more gracefully.

Otherwise i would suggest to contact the vendor of that product so that is providing a Set-Cookie string in a well-formed format (e.g. it has also two ;;).


Thanks for your quick answer. You’re probably right that his is not really in line with the RFC. However, the introducing sentence for the Grammar section seems to be somewhat relevant as well:

Servers SHOULD NOT send Set-Cookie headers that fail to conform to the following grammar:

That leaves at least some room for deviating from the suggested grammar. That is probably also the reason why browser are parsing the cookie information correctly. I tested with Firefox and Chromium:



Anyways: I opened a ticket for Wiki.js as well (https://github.com/requarks/wiki/discussions/6051).


Thanks a lot for your additional research / tests.

Unfortunately RFC related topics are always quite difficult to handle because there might be software strictly following the RFC (and ignoring everything not strictly following the RFC) while other software is “more lax” on the rules or interpreting them differently.

We will do some additional checks / tests from our side to see if it is safe to make the regex less strict.

This might take some time due to other priorities but the post will be updated once this is done to include our conclusion.


Rather have a false positive than a false negative. +1 for following the strict interpretation of the RFC.