Customize the Content Security Policy for Your Site

A Content Security Policy (CSP) is a security standard that provides websites with an additional layer of protection from cross-site scripting (XSS), clickjacking, and other code injection attacks. It is implemented using the Content-Security-Policy HTTP security header.  

The product engineering team released an enhancement to allow us the customization of the CSP header for Web Evolve websites. We have already defined in the CSP all the minimum required resources that must be allowed for the Evolve application to function, and can now further modify the CSP header for each website to add additional resources to the following directives:

• default-src
• style-src
• script-src
• form-action
• frame-ancestors 

You can see the current CSP implemented for your site using the CSP Evaluator provided by Google. Simply input your website URL and click Check CSP.

You must contact Support to make any changes to your CSP.

What to Submit to CivicPlus

For each directive you would like to customize, provide us with a list of domains that should be trusted along with the protocols that should be allowed: http and https or https only (recommended). There are specific directives we can put these domains into but most directives will use the default-src domains if nothing is specifically defined there. One exception to this is the frame-ancestors directive, which specifies which other sites are allowed to iframe any part of your site into their content. The frame-ancestors directive must be defined specifically, as it does not inherit resource allowances from the default-src directive.

Define the following directives, at a minimum, when customizing your CSP:

• default-src: What domains should be trusted in general for any "fetch" directives. Please read this Content Security Policy Cheat Sheet for more information on fetch directives. 
• frame-ancestors: Which URLs can embed any part of your site as an iframe. This is not a 'fetch' directive so it needs to be defined separately from the default-src domains to allow this. This directive is used instead of the X-frame-Options header and provides clickjacking protection for your website.

Other directives that can be specifically defined, when customizing your CSP:

• style-src: Where should we allow styles to be loaded from, such as fonts.googleapis.com has already been added. If you are loading styles from anywhere else besides the ones we normally use you can add those resources here.
• script-src: Where can scripts be loaded from onto your site, such as https://www.google-analytics.com for Google Analytics has already been added. If you have added any custom HTML widgets, you will want to note what resources are being used for those, such as do you use MailChimp scripts anywhere.
• form-action: Where forms can be submitted. Currently set to only the site (self).

FAQs

For style-src and script-src: currently, we have 'unsafe-inline' specified. This allows us to use inline styles and JavaScript, thus ensuring nothing breaks in the current implementation, correct?

This is correct.

The script_src directive has 'unsafe-eval' specified. Is this also required due to the functionality we're currently using on the site?

This is also correct.

If we work toward more best practice implementation, removing inline JavaScript and styles, would we be able to remove those expressions (unsafe-inline and unsafe-eval) in the future or are they required for other reasons?

We do not have in mind to remove these in the future. They are part of the system for several places where we offer functionality and flexibility on the system, including performance.