Manage web browsers - new CORS behavior

The Chrome 79 version update introduces a new policy regarding CORS request cookie management, which is disabled by default but can be activated.

As explained in the Chromium blogpost, the Chrome team is

planning to resume our SameSite cookie enforcement coinciding with the stable release of Chrome 84 on July 14, with enforcement enabled for Chrome 80+.

This policy will then be the default behavior implemented in all other browsers.

These changes were made as part of the ongoing effort to improve privacy and security across the web. This will force websites to use secure connections when they use “unsafe” cross site requests (POST/PUT/DELETE/PATCH/CONNECT), and thus avoid cookie hijacking.

We will explain in this article :

• what those changes are
• how to handle them in a Bonita deployment

What are the changes?

These changes concern the “SameSite” cookie attribute. Two new behaviours will be implemented:

• First, the SameSite attribute will now have a default value.

This default value will be “lax”, which implies that cookies will only be sent with a same-site request, or with a cross-site top-level navigation with a "safe" HTTP method (here “safe” means read-only request, like GET / HEAD / OPTIONS / TRACE).

• Then, if SameSite is configured to “None”, a Secure connection will be required.

This configuration allows cookies to be sent with both same-site and cross-site requests.

To find out more about SameSite cookies attribute, take a look at this good article on the subject:

https://web.dev/samesite-cookies-explained/

What are the possible impacts on a Bonita platform?

Beginning with Bonita version 7.11, we have made changes to anticipate the new behaviour. As you can see in the Bonita documentation page Enable CORS in Tomcat bundle, the default SameSite cookie configuration has been set to “lax.”

If you're not using CORS, then these changes will have no functional impact. The SameSite cookies attribute will now appear as “lax,” and as all requests are performed within pages with the same origin as Bonita REST API, all your cookies will still be sent.

Otherwise, if CORS is enabled on your Bonita server, you may no longer be able to perform CORS unsafe requests, depending on your Chrome browser version and your Bonita configuration.

How to manage as a CORS Bonita user

• You need to be able to have a test environment to simulate the new browser behaviour, and be able to monitor the problem.

To do this, you can follow the testing tips provided by the Chrome team. This will allow you to configure your Chrome browser to simulate the behaviour.

Depending on your usage, different configurations are required.

Case 1: If you only need to read information by calling the Bonita API, using GET HTTP methods ("safe" HTTP method as described in HTTP standards)

Configuration to be done: After configuring CORS by following the Bonita documentation, there is nothing left to do.

Case 2: If you need to modify data through the API by calling the Bonita API, using POST/PUT/DELETE HTTP methods (by using “unsafe” HTTP methods)

Configuration to be done: As explained in this article, you will need to change the SameSite cookie attribute to “None”, which will require a secure connection. Thus, two actions are required:

• Set up SSL in your Bonita server for a secure connection
• Modify the Bonita Tomcat bundle conf/context.xml file, to set sameSiteCookies to "none" instead of "lax".

It is evident that this push towards increased security from internet browsers will have a wide range of impacts on all web applications that use CORS, since “Unsafe” requests will no longer be possible without deploying your applications on a server secured with HTTPS.

But it is surely for the best.

Post written by dumitru.corini_1385394 and julien.mege