In this article, the example shows
However, a check on my server response show
This may be a stupid question but, does the order matter?
According to RFC 6265 section 5.2, the individual attributes of the Set-Cookie header are processed in whatever order they're found, and the Secure and HttpOnly attributes are simply used to set discrete values with no reference or relation between the two:
If the cookie-attribute-list contains an attribute with an attribute-name of "Secure", set the cookie's secure-only-flag to true. Otherwise, set the cookie's secure-only-flag to false.
If the cookie-attribute-list contains an attribute with an attribute-name of "HttpOnly", set the cookie's http-only-flag to true. Otherwise, set the cookie's http-only-flag to false.
So, no, according to the RFC the order they're listed in doesn't matter. Each will set a single flag, regardless of whether the other is absent, present, or in a varying order.
I've also never heard of an implementation that cared about the order (while I'm sure something, somewhere, somehow, gets this wrong - I wouldn't worry about it).
Note that this is a slightly different question than the one @BadSkillz referenced in his comment - that has to do with the order of headers; this has to do with the order of fields within a particular header.
Completely coincidentally, I enabled Secure and HttpOnly flags for F5 ASM cookies on one of my systems today. The F5 ASM will tack two cookies on to help do it's WAF-y magic. As soon as I enabled it I tested and these are the cookies they sent (... for width):
Set-Cookie: TS01145f87=01ca34131874c763...6207; Path=/; Secure; HTTPOnly
Set-Cookie: TS013fdbf2=01ca341318b0cba9...b198; path=/ui/; HTTPonly; Secure
So for two cookies set by one piece of software with one configuration point, it ended up with different orders for the attributes.