What errors are you seeing? what's in the browser console?

Thanks Quan. I checked the console and it looked to be an error that was caused by the Content-Security-Policy header specifically.

Refused to execute inline script because it violates the following Content Security Policy directive: "default-src 'self'". Either the 'unsafe-inline' keyword, a hash ('sha256-x...sw='), or a nonce ('nonce-...') is required to enable inline execution. Note also that 'script-src' was not explicitly set, so 'default-src' is used as a fallback.

Removing this header in particular solved the issue. I can revisit fixing the values inside our CSP, but for now this works.  

There is some information available about the CSP in the documentation here:
https://docs.developers.optimizely.com/content-cloud/v12.0.0-content-cloud/docs/content-security-policy 

Larry, have you considered looking into packages within the Optimizely Community?

There is Jhoose.Security.Admin which allows you to manage your CSP within the CMS which you can read more on here: https://github.com/andrewmarkham/contentsecuritypolicy 

Thanks Ynze and Mark for the links to the documentation. I will definitely be looking into Jhoose Security Admin. This is great.  

Jhoose is very easy to get started with, you can turn OFF the default policies if desired:

services.AddJhooseSecurity(_configuration, (securityOptions) =>
{
    securityOptions.StrictTransportSecurity.Enabled = false;
    securityOptions.XFrameOptions.Enabled = false;
    securityOptions.XContentTypeOptions.Enabled = false;
    securityOptions.XPermittedCrossDomainPolicies.Enabled = false;
    securityOptions.ReferrerPolicy.Enabled = false;
    securityOptions.CrossOriginEmbedderPolicy.Enabled = false;
    securityOptions.CrossOriginOpenerPolicy.Enabled = false;
    securityOptions.CrossOriginResourcePolicy.Enabled = false;
});

I'll also add that since I made my previous recommendation around Jhoose Security, I've also released my own module Stott Security.

It's free to use and allows you to edit all of the following headers within the CMS Administrator inteface complete with a full audit:

• Content Security Policy (CSP)
• Cross Origin Resource Sharing (CORS)
• X-Content-Type-Options
• X-Xss-Protection
• Referrer-Policy
• X-Frame-Options
• Cross-Origin-Embedder-Policy
• Cross-Origin-Opener-Policy
• Cross-Origin-Resource-Policy
• Strict-Transport-Security

You can read more here: https://github.com/GeekInTheNorth/Stott.Security.Optimizely

Both modules are great and work conceptually differently in terms of UI.  

Larry

Im adding these security headers with custom code, and for Content Security Policy (CSP) I had the same issue. It breaks the CMS. I resolved this by only applying CSP when Im not actually in the CMS. How to do this depends on how you are adding your headers. For me, Im adding these headers in some middleware. In that middleware I have a "ShouldAddCsp" method, and it looks at the url to determine where its happening:

private bool ShouldAddCsp(HttpContext context)
{
    var currentUrl = context.Request.Url();
    var path = currentUrl.PathAndQuery;
    var segments = path.Split('/', StringSplitOptions.RemoveEmptyEntries);

    var segmentZero = segments.ElementAtOrDefault(0);

    if (string.IsNullOrEmpty(segmentZero))
    {
        return true;
    }

    switch (segmentZero.ToLower())
    {
        case "error":
            return false;
        case "episerver":
            return false;
        case "util":
            return false;
        case "authorization-code":
            return false;
        case "signout":
            return false;
        case "cleaner":
            return false;
        case "form-handler-report":
            return false;
        case "translation-report":
            return false;
        case "translation-report-export":
            return false;
        case "redirectmanager":
            return false;
        default:
            return true;
    }
}

So, some of the URLS there are custom things I implemented. Your list of URLS may be different.