Investigate the use of the SameSite Directive for Cookies

[kevinreiss]

See https://web.dev/articles/samesite-cookies-explained. This could be a path to a more secure and efficient way to manage the cookies our applications create.

[kevinreiss]

Related to https://github.com/pulibrary/orangelight/issues/3896

[kevinreiss]

See comment from OIT on reports of cookie issues with SSO: https://github.com/pulibrary/orangelight/issues/3896#issuecomment-1857212948

[sandbergja]

I think we should set this directive to Strict (the default, which we currently use in the catalog, is Lax). It provides additional protection against CSRF (especially if our CORS is misconfigured), does not interfere with CAS logins, and is recommended by Mozilla. However, I don't think it will help much with https://github.com/pulibrary/orangelight/issues/3896 (huge Cookie headers caused by many large cookies set by other Princeton subdomains), since the SameSite directive considers all subdomains to be the same site.

The only drawback I see is the following scenario:

• A user logs into the catalog
• They navigate to some other site that is not in the Princeton domain (e.g. outlook)
• That other site includes a link back to the catalog
• The user clicks the link
• With SameSite=Strict, the user will need to log in again. With SameSite=Lax, the user is already logged in, saving them a step.

I found this from Mozilla, this from Portswigger, and this blog post from Andrew Lock to be helpful in understanding this topic.

[sandbergja]

Investigation complete, we opened tickets for the various applications to accomplish this.