Now that we have seen how CSP can be useful in preventing injections of content within your web pages, let’s have a look on some technical elements about CSP implementation, and a few ideas about the methodology to adopt.
As we have seen it in the first part of this article, Content Security Policy is a simple HTTP header, which can be easily set up. As an example, here is a configuration sample code for Apache:
<IfModule mod_headers.c> Header set Content-Security-Policy "script-src 'self' https://www.trusted-domain.com"</IfModule>
Some generators may help you handling the different options, as those provided by Report URI or cspisawesome.com.
However, you should be very careful before implementing CSP in production: one single mistake could cause a major breakdown on your website!
Luckily, the Content-Security-Policy-Report-Only header is here to help you. As you can guess, this header is equivalent to CSP, but will only report warnings in case of policy violation (without any blocking). Using this report only mode is consequently the best way to challenge your configuration.
Furthermore, it is possible to use both Content-Security-Policy and Content-Security-Policy-Report-Only headers. This can be very useful for an incremental approach in order to smoothly restrict the permissiveness of your security policy.
Before giving a go to your CSP implementation, take time to think about your workflow: who is allowed to add content? According which delay or validation process? Who will be in in charge of CSP updates? This could help you to avoid some major further issues. For example, don’t forget to think about tag managers. They usually offer a great flexibility to the marketing people, but most of time, the workflows won’t be compatible with CSP.
Content Security Policy options (directives and values)
default-src | Default policy, used in any case except if overridden by a more precise directive. |
script-src | Policy dedicated to scripts |
object-src | Policy dedicated to plugins (object, embed, or applet) |
style-src | Policy dedicated to styles (CSS) |
img-src | Policy dedicated to images (img, but also url() or image() from CSS, or link element related to an image type (ex: rel=”icon”) |
media-src | Policy dedicated to media (video, audio, source, or track) |
frame-src | Policy dedicated to frames (iframe or frame) |
font-src | Policy dedicated to fonts |
connect-src | Policy dedicated to connections from a XMLHttpRequest object or a WebSocket |
report-uri | Allows to define an URI to where CSP violation reports will be sent. If a piece of content is blocked by a browser, the browser will send a report with detailed information to this URI. Be careful: if your traffic is high, this could mean a lot of reports! |
Concerning the values, xxx-src directives allow ‘none’, * (for all), and combinations of these values:
–’self’ (current domain)
– list of domains (comma separated. Possible to use *.mydomain.com)
– data: (to allow base64 images for example)
Both script-src and style-src allow ‘unsafe-inline’ value too, in order to accept inline scripts and styles within your HTML code.
As a consequence, beware of side-effects you could experience with the default-src directive, that do not allow the ‘unsafe-inline’ value. Using this directive without adding style-src ‘unsafe-inline’ will block all your inline styles!
CSP level 2 has introduced some new directives: base-uri, child-src, form-action, frame-ancestors and plugin-types. Furthermore, CSP2 offers more granularity, by allowing specific scripts or inline styles for example. To go further, you can read the specification. I invite your to make sure to especially remember this paragraph:
In order to protect against Cross-Site Scripting (XSS), web application authors SHOULD include:
- both the script-src and object-src directives, or
- include a default-src directive, which covers both scripts and plugins.
In either case, authors SHOULD NOT include either ‘unsafe-inline’ or data: as valid sources in their policies. Both enable XSS attacks by allowing code to be included directly in the document itself; they are best avoided completely.
CSP: with great power comes great responsibility
To conclude about CSP, it’s a powerful tool, with benefits going way further than an additional security layer to your website. Even if implementing CSP on complex websites might seem difficult, CSP comes with a Report Only mode, allowing an incremental and less risky usage.
Knowing how frequent XSS vulnerabilities are, as well as issues that can be related to third-party content, the implementation effort immediately appears much more acceptable
If you wish to go further, you’ll be happy to find a lot of interesting resources within the CSP-useful repository.
Awesome, Thanks for the info.