[Updated 2019-03-17] Are you wondering why some JavaScript code from external domains simply won’t execute on your website? The reason could be as simple as an overly restrictive Content Security Policy (CSP for short). This article explains how you can create a Content Security Policy that’s both protective and functional. It will help you to secure your web server from some types of cross-site request forgery (XSRF\/CSRF\/XFS), clickjacking and other code injection attacks.<\/p>\n
<\/p>\n
Have you seen malicious activity in your web server logs or in your analytics suite? Don’t panic. By using a Content Security Policy, you can defend your infrastructure against cross-site request scripting and cross-site request forgery.<\/p>\n
A Content Security Policy (CSP) is a set of directives for the web server can block any content sources except for those you specifically approve (such as your own CDN or your advertising networks). This can considerably limit the exposure of your web applications to content injection and request forgery attacks. With a CSP in place, you take away one major incentive for your users to deactivate JavaScript and give them one more reason to trust your web application.<\/p>\n
If your website is using JavaScript\u2014either externalized or inline\u2014you do need a Content Security Policy.<\/p>\n
You as the web administrator, along with your web developers, are responsible for ensuring the safety of visitors who trust the code you deploy. A correctly configured Content Security Policy goes a long way towards that end by telling the browser which scripts you explicitly authorize to run on your domain.<\/p>\n
How do you know if your website has a Content Security Policy in place? One way to quickly verify if security headers are set it is by using the free service\u00a0https:\/\/securityheaders.io\/<\/a>. This service will list any directives you have in place, but it can’t judge if your Content Security Policy headers make sense. You have to make that decision yourself.<\/p>\n A Content Security Policy defines a set of trusted domains. It says that you want your visitors’ web browsers to trust them\u00a0 when executing JavaScript (and usually, distrust anything else).<\/p>\n A web browser reads the Content Security Policy from the HTTP\u00a0Content Security Policy header<\/strong> that your web server sends alongside your website content. As of this writing, all reasonably current web browsers support this feature<\/a>. A web browser which supports this feature will block the execution of JavaScript from all sources you do not approve of, thus rendering cross-site request forgery (XSRF\/CSRF\/XFS) attempts totally ineffective (the mechanics of cross-site request forgery are detailed in this OWASP document<\/a>).<\/p>\n For example, you may want to embed JavaScript from a web analytics service (such as Google Analytics), a social media widget (Facebook, Twitter, etc.), or an advertising network and disable the execution of code from all other domains, which you haven’t explicitly approved. All you need to do is whitelist the domains you consider trustworthy in the HTTP\u00a0Content Security Policy header.<\/p>\n A Content Security Policy is a whitelist of origin domains of scripts that you consider trustworthy. It is not a firewall. With some additional effort, an attacker might be able to circumvent your CSP. For example like this (see this GitHubGist<\/a> and also this<\/a> post by David Gilbertson):<\/p>\nHow a Content Security Policy protects your web application<\/h2>\n
The HTTP Content Security Policy header<\/h3>\n
The limitations of CSP<\/h3>\n