HTML and Web Applications are the dominant applications of our time. HTML was originally designed as a read-only documentation format and over time became rich, interactive. Many popular web applications today accept user-generated content (comments, images, etc.) and then display to other users.
In addition, as the web has become more complex, sites have adopted libraries from many 3rd parties, including ones which dynamically choose content such as advertisements and news feeds.
Many different tools have been created addressing this challenge, but today we will talk about the most powerful (and most complex), Content-Security-Policy.
Content-Security-Policy is a header that a web site emits, instructing the browser what to allow and deny. It is broken down by type (fonts, CSS, images, etc), and by domain (self, inline, other websites).
A strong, secure Content-Security-Policy will only allow `self`. This means that nothing hosted anywhere other than the source web server is allowed. However, this is not very realistic, it prohibits e.g. Google Analytics, fonts served from a CDN, etc. Previously I showed how to use Google Tag Manager with Content-Security-Manager.
The risks you are protecting against with a strong Content-Security-Policy are unsafe 3rd party code being evaluated in the page model of the browser for your web page. Some pages are more sensitive than others (login pages, form submittals). However, with modern applications, a session cookie or a JSON Web Token (JWT) representing the login and permission, are available on all pages: we need the Content-Security-Policy to be strong on all pages.
A hybrid between `self` and named sites is called `subresource-integrity`. In this model, a signature of the content is performed. If it matches, it is allowed. This is far more flexible than trying to estimate all possible sources of 3rd party content. However, it can be challenging to set up since all libraries must support it.
If possible, use either `self` or subresource-integrity for all types. Block `object`. Do not allow `unsafe-inline` or `unsafe-eval` or `data:`.
If you have an Angular application, I recommend compiling it as
ng build --aot --subresourceIntegrity --outputHashing=all --prod=true
An excellent resource to assess your Content-Security-Policy is the Mozilla Observatory.
If you own and operate a web application, whether it be a static site like WordPress, or an e-commerce site, you must setup your Content-Security-Policy. No exceptions. Your customers fate rests in your hands, be responsible.