decap-cms: CMS does not work with Content Security Policy (CSP). Requires unsafe-eval / unsafe-inline for script-src / style-src

A compromise option that might be viable is to only do dynamic validation if we detect that we need to because there are widgets registered with custom schemas. Widgets registered that do not have any additional schema would not require any dynamic validation.

// defined at build time
import { staticValidateConfig } from './config.schema.json';

export function validateConfig(config) {
  if (Object.values(getWidgetSchemas().find(schema => !!Object.keys(schema)))) {
    // there are custom widget schemas, we can't use the static validation
    // this is the current `validateConfig` function.
    // this will trigger a CSP error unless `unsafe-eval` is set.
    return dynamicValidateConfig(config)
  } else {
    return staticValidateConfig(config);
  }
}

It’s a bit of a strange implicit opt-out, but it does have the advantage of being backwards compatible.

@erezrokah After doing some more digging, coding, and research, we’re really close on this, but there is one final stumble that we’re hitting.

We were able to completely extract the schema, and build the validateConfig function at build time. This works for our site, but there are cases where it will not work for everyone. Specifically, the schema itself can change dynamically based on widget schemas that are added via registerWidget() https://github.com/netlify/netlify-cms/blob/2877f7983e9b5f4ff0cb2cdaaf6549675af68913/packages/netlify-cms-core/src/constants/configSchema.js#L75

Unfortunately, registering widgets happens in the browser, and so it cannot be known at build-time what the complete schema will be including widget extensions.

It seems to me that the only way this can work correctly is to deprecate registration of pieces of schema along with widgets and instead make the schema for user-supplied widgets sufficiently broad to type-check against any widget config. That’s a breaking change and would mean slightly less type-safety for config.yaml, but it also means that it can be deployed with a secure content policy because the entire schema would be known at build time.

We’re investing so much effort in this because we really like Netlify CMS, but unsafe-eval is unfortunately a deal breaker for our security team. We’d love to find a way forward here, but not really sure what to do at this point.

I should add that I was able to resolve some of the non-eval issues by using sha256 hashes in script-src (not the ones generated here, but only the ones Google Chrome shows when an element is blocked). The eval issue remains, however, and further inline-styles are required once you get past the initially blocked evals / inlines. It would appear that some of the initial issues were caused by the Netlify Identity widget, but once those are out of the way, further issues crop up when trying to load /admin/

edit:

Because I can’t get very clear error messages from Firefox or Chrome, this issue is very hard to diagnose. It seems as though the issues start with the Netlify identity widget and then continue when trying to load the CMS. The identity widget throws an script-src eval-violation in Firefox, but not in Chrome. In Chrome, the identity widget throws a style-src unsafe-inline violation, which does not show in Firefox.

In Firefox, this is where the buck stops. In Chrome, I can advance to the /admin/ URL, where the CMS itself will provide the following error EvalError: Refused to evaluate a string as JavaScript because 'unsafe-eval' is not an allowed source of script in the following Content Security Policy directive: "script-src 'self' 'sha256-Y1ZIa2N59dlCRGtBP67/dCOpq2eDNPEO+vGJU0pjvEw=' 'sha256-jILZY2UBo/ux6K6qGHntQonoJYNQZfxdLrszRmDpc/o=' 'sha256-v40OvYf1mF3VQM75141gVEb6xZk97Wd9tDERTFg3N38=' 'sha256-tphCtOfPA2HxpbQIjyGzEOxfajrm+crnavJGIhdlT7k=' https://www.google.com https://www.googletagmanager.com https://www.gstatic.com https://identity.netlify.com https://cdn.jsdelivr.net https://www.google-analytics.com".

Chrome also throws multiple inline-style errors and the eval error mentioned before. I believe that without unsafe-inline and unsafe-eval it won’t be possible to run either the identity widget or the CMS.

For the style-src issues I think it’s down to react components’ usage of inline-styles. For eval, you have to look further as it’s not just eval itself, but it’s also related functions.

I found a discussion regarding react from 2016 and one from 2018 regarding this.

In a recent e-mail conversation, Netlify have confirmed that they have a feature request to fix this, but are not actively looking into it, so for now I shall give up. I’ll leave this information here for someone to revisit one day.

Any updates here?

I like that idea @cowboyd 💡 !