Jaxrs-api: NewCookie should support SameSite attribute

[chkal]

The NewCookie class should support the SameSite cookie attribute. The Jakarta Servlet project is working on adding support for SameSite as well in eclipse-ee4j/servlet-api#271.

I'm currently working on pull request containing a first draft of the required changes for the JAX-RS API.

[mkarg]

Can you please provide a RFC reference for SameSite? I only can find https://tools.ietf.org/id/draft-ietf-httpbis-rfc6265bis-03.html which says it is outdated and was not approved. We need to be on the safe side that the literals we provide are note replaced by a subsequent RFC. Thanks. :-)

[chkal]

AFAIK this is the most recent version:

https://datatracker.ietf.org/doc/draft-ietf-httpbis-rfc6265bis/

[mkarg]

AFAIK this is the most recent version:

https://datatracker.ietf.org/doc/draft-ietf-httpbis-rfc6265bis/

Thanks a lot. That document says that it is still a draft and work-in-progress, so it might not be wise to include it in master. My proposal would be to add it once it is at least it a post-draft state, as the IETF explicitly mentions that this document can be replaced within six months:

Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

[chkal]

I fully understand your concerns about the RFC's draft state. However, there are many good arguments for integrating this feature into JAX-RS 3.1:

• The SameSite attribute in its current form exists in RFC drafts since 2016 (see draft-ietf-httpbis-cookie-same-site) and this aspect of the RFC hasn't changed since then. So in some regard it can be considered to be stable.
• All major browser already support the SameSite attribute since a few years, even IE11 which doesn't count as a modern browser. And I'm pretty sure that the browser vendors take special care when choosing which draft features to implement.
• The SameSite attribute is a very important feature for protecting against cross-site request forgery. OWASP for example recommends to use SameSite to protect against such attacks. Unfortunately Jakarta EE developers are unable to enable this protection today making their applications more vulnerable to XSS attacks.
• Modern browsers are starting to apply SameSite=Lax by default (see here). So if your application requires cross site cookies for some reason, you MUST set SameSite=None or your application will break.

So IMO there are definitely more pros than cons for adding this feature.

[mkarg]

I completely understand the benefits, but we cannot undo it once we adopt it, and the authority of all this, the IETF, themselves so far did not dare to declare the draft as an adopted standard for a good reason I think. I wonder what their reason is, and why the last draft did time out without adoption? It seems, the vendors are not so sure to keep it - BTW, vendors do drop support for non-standards from time to time. I will not stand in the way of your MR if the vendors think it is worth taking this risk. I just want to point out that I personally would like the IETF to decide first and will abstain from this vote due to that formal reason - I completely like your contribution itself.

[chkal]

I completely understand the benefits, but we cannot undo it once we adopt it, [...]

I don't think that there will be a need to "undo" this change regardless of the RFC outcome. The SameSite attribute is at least a de-facto standard. In the worst case scenario, the RFC may drop one of the possible attribute values (like Lax or Strict) or add a new one. But in this case we can add a new value to our enum and/or deprecate the old one. IMO that would be acceptable.

and the authority of all this, the IETF, themselves so far did not dare to declare the draft as an adopted standard _for a good reason_ I think. I wonder what their reason is, and why the last draft did time out without adoption? It seems, the vendors are not _so_ sure to keep it

Just to clarify: The RFC doesn't cover only the SameSite attribute. It is about cookies in general and covers all the aspects related to them (user agent requirement, security considerations, etc.). Actually the SameSite attribute is only covered in one of the 53 pages. So SameSite is just a small aspect of the RFC and the fact that it isn't final doesn't necessarily have to do with SameSite.

I just want to point out that I personally would like the IETF to decide first and will abstain from this vote due to that formal reason - I completely like your contribution itself.

I agree that it would be better if the IETF completes the RFC first. However, IMO the benefits mention before outweigh the risk. But that's just my opinion. :-)

[fstokke]

I agree that this should be supported. It's an important security feature that is already widely adopted.

As a work-around it seems you can put the SameSite flag into NewCookie path field, e.g. path="/;SameSite=Strict" (or add the cookie manually via a set-cookie header).

Maybe a generic mechanism for adding "non-standard" flags can be added to the API?

[chkal]

Maybe a generic mechanism for adding "non-standard" flags can be added to the API?

Interesting idea. Feel free to file an issue for that.

[chkal]

868 has just been merged!

[mkarg]

Maybe a generic mechanism for adding "non-standard" flags can be added to the API?

Interesting idea. Feel free to file an issue for that.

Please comment on https://github.com/eclipse-ee4j/jaxrs-api/issues/877 :-)