CSP is the Content Security Policy for your website’s pages. Think of it as a foreman on a construction site, checking all the material loads coming to the gate, verifying that they meet the requirements and sources defined by you, the architect. Accepting pine paneling for oak paneling in the specs would be disastrous for a number of reasons. First, they do not look or feel the same. Secondly, and most importantly, oak is a high-quality and strong wood, much stronger than pine, able to withstand greater pressure and last longer. Websites are not the same as a building, clearly, but in my opinion, this example remains viable.

So what does this mean for a website? Foremost, as stated in its name, it’s security. It mitigates the risk of malicious scripts executing in your site through XSS attacks, and blocks sources from which CSS, images, or JavaScript can be loaded. A common example of this is custom HTML provided by a user, perhaps through a rich-text editor, that will be rendered on a page on your site. That HTML can easily contain script, style, or image tags loading content from off-site (your rich-text editor very likely contains methods or filters for controlling these tags, and you should be leveraging them), and that content can be malicious. Recently, there has been a spate of PDFs and even SVGs that contain malicious code. It’s possible to embed JavaScript and dangerous links in an SVG, as it is composed of XML. You don’t want to expose your users and yourself to phishing attempts or JavaScript that is acting nefariously. Hence, Content Security Policy (CSP).

There are a couple of methods for implementing CSP: configuring Nginx, Apache, or IIS to add a CSP header for every request, or adding a <meta> tag that defines your CSP. While the first method may be common, the second method, in my opinion, is the easiest and most accessible. If a change to the CSP is needed, you only need to make a change to the <meta> tag rather than getting a sysop involved.

Here’s an example of a CSP defined in a <meta> tag:

<meta http-equiv="Content-Security-Policy"          
   content="default-src *;          
       font-src 'self' https: data:;     
       style-src 'self' unpkg.com cdnjs.cloudflare.com cdn.datatables.net;
       img-src 'self' data: cdn.datatables.net *.google.com *.gstatic.com;
       script-src 'self' www.google-analytics.com maps.google.com unpkg.com 
	       cdnjs.cloudflare.com cdn.datatables.net *.googletagmanager.com 
	       *.google.com *.gstatic.com;"
 >

Note: I’ve munged the formatting a bit here for readability. The content will depend on the needs of your own website, of course.

With the above CSP in place, if a user uploads custom HTML to your site to render, and it includes any stylesheets or images that come from off-site, such as imageshack.com, they will fail and be logged in the console of the browser. Likely, there will be several tweaks required, and you should reference https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/CSP for documentation.

If you are not currently implementing CSP on your website, I highly recommend it. Read the CSP docs, and you will see examples that should raise the hairs on the back of your neck.