When navigating to the SPA channels, the following warning appears inside Chrome:

A cookie associated with a cross-site resource at http://hap-saas.eng02.bloomreach.cloud/ was set without the `SameSite` attribute. A future release of Chrome will only deliver cookies with cross-site requests if they are set with `SameSite=None` and `Secure`. You can review cookies in developer tools under Application>Storage>Cookies and see more details at https://www.chromestatus.com/feature/5088147346030592 and https://www.chromestatus.com/feature/5633521622188032.

__Chrome was rolling out this release incrementally, but stopped, rolled back and delayed the full rollout until the summer. We should be prepared for the SameSite cookies enforcement and have it for the next release.

Problem description

When an SPA is rendered in the CM, this is typically done from a different domain than the CMS runs on. The SPA in the CM however needs to load cms angular channel manager resources : This is thus cross-origin. However, cms angular channel manager resources are only allowed to be loaded for logged in CMS users, see CMS-10733 : Most likely the secure resources were introduces since the resources are loaded from a jar, and we do not want for example .class files to be possible to request for anonymous users.

Because of the Secure resource servlet, the SPA does these requests with SameSite flag such that credentials cookies are send along with the request (from SPA domain in browser a call to CMS domain). Then the secure resource servlet returns the resources with

resp.setHeader("Access-Control-Allow-Origin", origin);
resp.setHeader("Access-Control-Allow-Credentials", "true");
resp.setHeader("Vary", "Origin");

Currently, for the CMS domain http session, we do not set any SameSite value. Chrome will change the default SameSite behavior to 'Lax' when not set in the future. From then on, the credentails will only be included for top-level GET requests. We could fix it by setting SameSite = None for our CMS http session, but that opens up vulnerabilities.

[1] https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Set-Cookie/SameSite

Suggested fix

Since we should not set SameSite = None for our CMS http session, I propose to change the SecureCmsResourceServlet to not check on whether there is a valid logged in user any more (an odd check any way imho). The SecureCmsResourceServlet will behave exactly the same as the ResourceServlet, which already does whitelisting on:

        DEFAULT_ALLOWED_RESOURCE_PATHS.add(Pattern.compile("^/.*\\.html"));
        DEFAULT_ALLOWED_RESOURCE_PATHS.add(Pattern.compile("^/.*\\.js"));
        DEFAULT_ALLOWED_RESOURCE_PATHS.add(Pattern.compile("^/.*\\.css"));
        DEFAULT_ALLOWED_RESOURCE_PATHS.add(Pattern.compile("^/.*\\.png"));
        DEFAULT_ALLOWED_RESOURCE_PATHS.add(Pattern.compile("^/.*\\.gif"));
        DEFAULT_ALLOWED_RESOURCE_PATHS.add(Pattern.compile("^/.*\\.ico"));
        DEFAULT_ALLOWED_RESOURCE_PATHS.add(Pattern.compile("^/.*\\.jpg"));
        DEFAULT_ALLOWED_RESOURCE_PATHS.add(Pattern.compile("^/.*\\.jpeg"));
        DEFAULT_ALLOWED_RESOURCE_PATHS.add(Pattern.compile("^/.*\\.json"));
        DEFAULT_ALLOWED_RESOURCE_PATHS.add(Pattern.compile("^/.*\\.eot"));
        DEFAULT_ALLOWED_RESOURCE_PATHS.add(Pattern.compile("^/.*\\.map"));
        DEFAULT_ALLOWED_RESOURCE_PATHS.add(Pattern.compile("^/.*\\.otf"));
        DEFAULT_ALLOWED_RESOURCE_PATHS.add(Pattern.compile("^/.*\\.svg"));
        DEFAULT_ALLOWED_RESOURCE_PATHS.add(Pattern.compile("^/.*\\.swf"));
        DEFAULT_ALLOWED_RESOURCE_PATHS.add(Pattern.compile("^/.*\\.ttf"));
        DEFAULT_ALLOWED_RESOURCE_PATHS.add(Pattern.compile("^/.*\\.woff"));
        DEFAULT_ALLOWED_RESOURCE_PATHS.add(Pattern.compile("^/.*\\.woff2"));

The advantage of this changing SecureCmsResourceServlet is that it requires no action or changes by end projects and is BC. However, it does change the behavior although it is BC. If a customer really wants to restore the old SecureCmsResourceServlet, we will add a configuration option (though the web.xml) to restore the old SecureCmsResourceServlet behavior