If you do not need certain types of content for a page or the entire website, you can enter the value 'none' in the header – so you can specify that no sources may be loaded at all. You can also use the value 'self' – this means that the browser can only load content from the same source. Both values must always be quoted in single quotation marks, otherwise none and self will be interpreted as domains.
There are different header options for defining a Content Security Policy:
- Content-Security-Policy
- X-Webkit-CSP
- X-Content-Security-Policy
Not all browsers support every term. However, the W3C (the body responsible for defining web standards) suggests Content Security Policy. Therefore, all modern browsers have adapted to this security standard in the meantime (the other two versions are considered obsolete). To make sure that you reach as many internet users as possible (even those with out-of-date browsers) with your CSP, it is advisable to include all header fields. If a corresponding web browser can’t handle the Content Security Policy header, it will simply ignore it and display the website without any problems – however, additional protection isn’t given to the affected users.
Usually, you will set HTTP headers across your entire domain. For sub-directories, you can use the .htaccess file. You then use the CSP security standard to set special rules for individual subpages. For example, if you have implemented a social media button on one page, but not on the next one, it makes sense to only allow access to the external source on the first page.
Sources can be entered as addresses, in their own way or as wildcards. The following entries are therefore allowed:
- script-src example.com:443 – scripts are only allowed from this domain via HTTPS
- script-src 'none' – scripts aren’t allowed to be loaded
- script-src 'self' – scripts may be loaded from the same source as the current page, but not from subdomains
- script-src https: – scripts can be loaded from any domain as long as it starts with HTTPS
- script-src example.com – scripts may be loaded from this domain
- script-src *.example.com – scripts from this domain and all subdomains are allowed
- img-src data: – images can be loaded via data URLs
A Content Security Policy basically stipulates that scripts may only be loaded from files, not directly from the website code. If you want to bypass this, you can use the command script-src 'unsafe-inline'. However, you should be aware that you are weakening security. The safety standard also prohibits the eval () feature. This command can be used to convert text into JavaScript code – but this can also pose a security risk. If you still need this function, you can reactivate it with script-src 'unsafe-eval'.