A new Set-Cookie header attribute is arriving, and the new attribute is called SameSite.
Google is making this new attribute a requirement in all cookies as of version 80 of the Chrome web browser, set for release on February 17, 2020 (with a slower rollout of that particular feature). Mozilla has committed to follow this requirement too for their Firefox web browser but their timeline is not yet determined. Other web browser vendors may follow suit in the future.
Gateway versions 9.4 CR3 and lower do not support the new SameSite attribute. Users must upgrade to support the new SameSite attribute. When running a Gateway version without support for the SameSite attribute, there may be observed policy violations or other impacts seen when a backend is adding the SameSite attribute and passing it back through the API Gateway.
This situation is being caused by a push from large vendors to require an attribute called SameSite in the Set-Cookie header. Since cookies are allowed to be named anything, the way the parser would work in the API Gateway (without support for SameSite) is that it would create a new cookie every-time it encountered any unknown attribute that wasn't already defined in the RFCs for the Set-Cookie header. As a result, the Gateway currently (without support for SameSite) ends up creating a second cookie named "SameSite" instead of leaving it as an attribute to an existing cookie, which can also make it appear that there are duplicate Domain and Path attributes in the header.
This impacts all API Gateway versions up to 9.4 CR3 and older.
To determine if there will be any impact to the environment, the following questions should be asked:
If the answer is "yes" to any of the questions above, then expect an impact to the environment and the mitigation for such an impact is to upgrade to a version that supports SameSite or to apply the hotfix as needed. Those who answered "no" may have less chance of an impact but are encouraged to upgrade regardless as it is a matter of when it happens rather than if it happens.
To be able to support cookies with the SameSite attribute, the only solution is to upgrade to a release that supports the SameSite attribute. Broadcom Support recommends upgrading to version 9.4 CR4 (as of February 2020). If upgrading to 9.4 CR4 cannot be done and Gateway 9.3 or lower are being used, then hotfixes can be utilized, however, hotfixes come with caveats which is why they are discouraged. Hotfixes are provided as-is and will overwrite existing hotfixes if there are already hotfixes being used in the API Gateway.
The 9.4 CR4 and related hotfixes can be downloaded from this page: https://techdocs.broadcom.com/us/product-content/recommended-reading/technical-document-index/ca-api-gateway-solutions-and-patches.html
It is important to understand that if the use-case is the Gateway setting the cookie as either the request or response, if any part of the workflow expects the SameSite attribute to be set, then it will need to be manually enabled in the appropriate assertions in policy which are setting the cookie. If the Gateway is just passing the cookie and not manipulating it, then there should be no expected manual intervention outside of applying the fix.
There are several great reading materials available online that can be used to better learn and understand what the SameSite attribute means, and for updates on the Chrome project with implementing this new attribute.
Tip: To know if an existing hotfix is already being used, run the following command on a bash prompt and check the output, if any of the ssg- or ssg-appliance RPMs contain DE<######> in the name, then an existing hotfix is already being used: rpm -qa | grep ssg