Content-Security-Policy
HTTP response header, but it can also be defined within a meta tag.
With CSP developers can restrict how resources are loaded by the browser to help prevent attacks such as Cross Site Scripting (XSS) or other injection attacks.
The main reason CSP is deployed is to improve the security of your web sites or web applications. CSP is enforced at the browser level, so as long as your users have a modern browser (one built within the last 5 years), they should have excellent support available for CSP.
Probably the biggest challenge when implementing CSP is dealing with legacy code. This is especially problematic if there are a lot of inline javascript event handlers or inline CSS. Inline code is automatically blocked by CSP, and you want to keep using inline code you need to write your code and your CSP policy to handle this properly. CSP has introduced some features that help developers such as the nonce or the CSP hash.
If your site loads a lot of third party content, it can be complex to create policies that work well with third party services. This can be especially challenging if the third party service is has not been implemented in a way that is friendly to CSP, for example if it injects scripts dynamically or injects inline styles.
CSP can be a great way to improve the security of your site, and significantly reduce the likelihood of successful XSS attacks.
CSP can also be a great assist in achieving script authorization, script integrity and script inventory defined in PCI version 4.
Want to learn the ins and outs CSP? Grab a copy of the CSP Developer Field Guide. It's a short and sweet guide to help developers get up to speed quickly.
Grab a CopyAdvisory Week is a weekly roundup of all the security advisories published by the major software vendors.