content-security-policy "default-src 'self'", for example, restricts loading of all content types to the domain (
default-src 'self'). This is a good starting point from which to define any exceptions. Say, for example, you want a web site to additionally be permitted to load scripts from h-online.com, you need to add the corresponding script source (
default-src 'self'; script-src http://h-online.com
The structure of the policy is easy to understand. The
content-security-policy header field is followed by a content type directive, which is in turn followed by arguments. Each directive can be assigned multiple arguments separated by spaces. In general, the arguments are simply lists of permitted sources. These can be complete URLs, domains or simply URL schemas such as http: and https:. The latter can, for example, be used to force the use of https.
The following directives are available:
|default-src||default sources for content where no specific directive is defined|
|font-src||permitted font sources|
|frame-src||permitted iFrame sources|
|img-src||permitted image sources|
|media-src||permitted sources for video and audio files|
|object-src||permitted sources for Flash and Java applets and other plugins|
|style-src||permitted sources for style sheets|
|report-uri||policy infringements are reported here|
|sandbox||sandbox rules, analogous to the sandbox attribute in HTML5|
The specification allows wildcards of the form http://*.h-online.com, but they should only be used in the Content Security Policy header, as the X-CSP and X-Webkit versions ignore everything after the star – in our example this would mean that all domains would be allowed. Brandon Sterne has released a CSP bookmarklet for defining exceptions. It analyses what content types a browser loads when calling pages from external sources and uses this information to create an appropriate whitelist.
There are also keywords that, somewhat idiosyncratically, have to be placed within single quotes.
'self' means that the content type can only be loaded from the same source.
'none' blocks a content type from being loaded altogether.
'unsafe-inline' can be used to re-enable scripts (via the
script-src directive) or inline CSS (via
style-src). As the
'unsafe-' prefix suggests, however, these options are to be avoided if at all possible.
A further default CSP restriction is a strict ban on the
eval() can be re-enabled using the
'unsafe-eval' argument for the
script-src directive. In Firefox's implementation of the X-Content-Security-Policy, unsafe switches are not entered as directive arguments, but are appended to the policy in the form of options:
X-Content-Security-Policy: default-src 'self'; options inline-script eval-script
The current Firefox implementation permits inline CSS.
Additional security is provided by using the value
'none' to forbid the use of unused content types. Where, for example, a web site does not normally use any plugins, an object-src
'none' ensures that the browser will never execute any plugins. Should an attacker manage to inject, say, a Java exploit into a web page, a CSP-compliant browser will simply not launch the applet. In future, it should be possible to enable different plugins individually.