In the 2 previous posts about Content Security Policy, we talked about the main reasons why you need to get started with CSP and the common problems that you will run into. In this post, we will dive deeper into the 3 types of CSP solutions.
Because reports of violations can be overwhelming for both analysis and performance reasons tCell recommends starting with the most critical directives first (such as script-src and object-src which help prevent XSS) and a very permissive set of sources that will produce few violations and reports. From there attempt to make it more restrictive source by source.
Strict-Dynamic & Nonces
Strict Dynamic was introduced in CSP 3 and allows some backward compatibility while moving to nones. You can see in the image below how strict dynamic allows transitions that allow older browsers to work while protecting browsers that support CSP3.
As a reminder, this means the Nonce should be dynamic each page load and the value should be made available to the template engine. Google, in their paper CSP is Dead, Long Live CSP , suggest strict-dynamic as a method to get good nonce coverage of all scripts, including scripts which reference other sites.
Track Inline Scripts That Already Exist
By keeping track of how many scripts have nonce’s you can track your progress and get an idea of how long the project will take.
If you’re interested in reading more about Content Security Policy, check out Content Security Policy: Newer CSP Directives & Common Problems to get a better understanding of the hurdles of CSP. We also have a post about the Top 3 Reasons to Get Started with Content Security Policy with a list of resources to help you get your CSP up and running. Enjoy!