Reading up on Content Security Policy (CSP) headers, there are a few that look like they might break the Sitecore Content Editor and Experience Editor, if implemented on the Content Management server.

What are the strongest (most restrictive) security settings for CSP that allow a fully functioning Sitecore client?


  • 1
    I've used upgrade-insecure-requests without issue. The setting blocked-all-mixed-content breaks the Workbox for sure. Feb 27 '18 at 1:16
  • 1
    Sitecore has added a KB article for CSP which states: the CSP definition for Content Management (CM) instance should definitely allow unsafe-inline and unsafe-eval scripts for the mapped CM hostname(s)
    – Jason
    May 16 '19 at 4:33

It doesn't have to break Sitecore itself; it depends on how restrictive you want to be.

I've found that I have to allow unsafe-inline and unsafe-eval for script, and most other media needs to be "self"

The project I'm working on currently uses the following (it's quite loose - lots of media from other domains):

default-src * 'self' 'unsafe-inline' ; script-src 'self' data: 'unsafe-inline' 'unsafe-eval' [remove various analytics] ; connect-src * ; upgrade-insecure-requests; block-all-mixed-content;

Seems to work okay, but you might want something more restrictive.

If so, a good option then would be to turn on your CSP in Report-Only mode. Set a policy something like:

default-src 'self' 'unsafe-inline' ; script-src 'self' 'unsafe-inline' ; upgrade-insecure-requests; block-all-mixed-content;

Use a service such as report-uri.com to record violations (or just monitor the console in Chrome's DevTools), and try using it for a while. Once you've got some violations, review, and adjust your policy.

  • Yes, we're planning on using report-only for some of the more tricky parts, and obviously what we can implement on content delivery is dependent on solution requirements. These are things that can be designed or refactored though. I'm mainly interested in the Sitecore content management server, as this isn't something we can recode. Mar 13 '18 at 12:51

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.