Contact us: info@akimbocore.com

HTTP Security Headers: Content-Security-Policy

Author: HollyGraceful    Published: 19 October 2020

Content Security Policy (CSP) allows the application to restrict the location of resources to an allow-list of approved locations, including where scripts can be loaded from and when the application may be framed. This can therefore mitigate reflected and stored cross-site scripting attacks as well as issues such as Clickjacking.

ClickJacking may also be prevented using the X-Frame-Options security, however this is not fully implemented in some browsers, for example in Chrome the only available options are DENY and SAMEORIGIN.

Content Security Policy is enabled by supplying a Content-Security-Policy HTTP response header. The CSP header is made up of two parts, a list of directives and a list of approved locations.

It is recommended that at a minimum the following directives are supplied: script-src, object-src, style-src, and frame-ancestors. It is also recommended that no directives marked as unsafe are included, for example 'unsafe-inline' and 'unsafe-eval'.

 

The following are examples of available directives:

default-srcA default allow-list for where more specific directives have not been supplied.
script-srcSpecifies where JavaScript can be loaded from.
img-srcSpecifies where images can be loaded from.
style-srcSpecifies where CSS can be loaded from.
connect-srcSpecifies where features such as XMLHttpRequest may connect to.
font-srcSpecifies where fonts may be loaded from.
object-srcSpecifies where object, embed, and applet elements may be loaded from.
media-srcSpecifies where audio, video and track elements may be loaded from.
frame-srcFrame-src is for where frames can be loaded from, which was deprecated in CSP Level 2 and then undeprecated in CSP Level 3.
frame-ancestorsSpecifies where this page may be framed from. Setting frame-ancestors to ‘none’ is the equivalent of setting the X-Frame-Options header to DENY.

 

The following are examples of source locations that can be given to directives:

*A wildcard to allow any URL except data: and filesystem: schemes.
‘none’Disables this resource type
‘self’Allows resources from the same-origin
data:Allows the loading of resources via the data scheme, such as base64 encoded images
domain.example.comAllows loading resources from the specified domain
*.example.comAllows loading resources from any subdomain of the specified domain
https://example.comAllow loading resources from the specified domain, if supplied over HTTPS
https:Allow loading resources from any domain, if supplied over HTTPS
‘unsafe-inline’With script-src, allows the use of inline JavaScript; considered unsafe as it may allow for Cross-site Scripting attacks. With style-src, allows the use of inline CSS; considered unsafe as it may allow for virtual defacement.
‘unsafe-eval’Allows the use of JavaScript eval(), a function, which may allow for DOM-XSS attacks. The eval() function is described by MDN as “an enormous security risk”.
‘sha256-‘Allow scripts to execute if they match the supplied hash. sha256-, sha384-, or sha512- may be used.
‘nonce-‘Allow scripts to be used if they include a nonce= attribute which matches the supplied none entry in the header. These numbers should not be used for more than one script, instead additional nonce- entries should be supplied.

 

The source list can be used, with the directives to build a policy. For example:

Content-Security-Policy: default-src: 'none'; script-src: js.example.com; img-src: static.example.com; font-src: static.example.com;

 

References