Content Security Policy (CSP)

Content Security Policy (CSP) is a whitelisting mechanism that allows you to control what behaviour is allowed in a particular page, mitigating the risk of content injection vulnerabilities such as Cross-site scripting.

Below are the goals that CSP aims to do:

1. Mitigate the risk of content-injection attacks by giving developers control over:
   • The resources which can be requested on behalf of a specific page
   • The execution of inline script
   • dynamic code execution (via eval() and similar constructs)
   • The appliation of inline style

1. Mitigate the risk of attacks which require a resource to be embedded in a malicious context by giving developers granular control over the origins which can embed a given resource.
2. Provide a policy framework which allows developers to reduce the privilege of their applications.
3. Provide a reporting mechanism which allows developers to detect flaws being exploited in the wild.

The various options you can use to configure CSP are called directives. CSP directives can be spcified using HTTP response header or HTTP Meta tag. The HTTP headers below are defined by the specs:

Content-Security-Policy : Defined by W3C Specs as standard header, used by Chrome version 25 and later, Firefox version 23 and later, Opera version 19 and later.

X-Content-Security-Policy : Used by Firefox until version 23, and Internet Explorer version 10 (which partially implements Content Security Policy).

X-WebKit-CSP : Used by Chrome until version 25

CSP example using HTTP header

Content-Security-Policy [directive] <value>;

Content-Security-Policy default-src 'self';

In the above example, the default-src directive with self value instructs that it wants all content to come from the website's own origin (excludes subdomain).

CSP example using meta tag

<meta http-equiv="Content-Security-Policy" content="default-src 'self';>

When using CSP in a meta tag, you will need to specify the policy within the head section of the HTML document.

Example Scenario: Developers for Example Inc. want to protect themselves against Cross-site scripting attacks. They can mitigate the risk of script injection by insuring that their trusted CDN is the only origin from which script can load and execute. They also want to ensure that no plugins can execute in their page contexts. Following is the Content Secrity Policy for this scenario:

Content-Security-Policy: script-src https://trusted-cdn.example.com/scripts/; object-src 'none'

Below are examples on how you can configure web servers to configure CSP directive usimg HTTP header.

Apache httpd server

Add the CSP directive in your VirtualHost section or in an .htaccess file.

Header set Content-Security-Policy "default-src 'self';"

Nginx web server

Add the CSP directive in your server block. e.g.

server {
listen 443 ssl http2;
...
location / {
...
add_header Content-Security-Policy "default-src 'self';";
...
}
...
}

Internet Information Services (IIS) Web Server

Add the CSP directive in your web.config

<system.webServer>
<httpProtocol>
<customHeaders>
<add name="Content-Security-Policy" value="default-src 'self';" />
</customHeaders>
</httpProtocol>
</system.webServer>

Supported CSP directives

• child-src: Controls requests which will populate a frame (e.g. <iframe> and <frame>) or a worker.
• default-src : Define loading policy for all resources type in case of a resource type dedicated directive is not defined (fallback).
• script-src : Define which scripts the protected resource can execute.
• object-src : Define from where the protected resource can load plugins.
• prefetch-src : Restricts the URLs from which resources may be prefetched or prerendered.
• style-src : Define which styles (CSS) the user applies to the protected resource.
• img-src : Define from where the protected resource can load images.
• media-src : Define from where the protected resource can load video and audio.
• frame-src : Define from where the protected resource can embed frames.
• font-src : Define from where the protected resource can load fonts.
• connect-src : Define which URIs the protected resource can load using script interfaces.
• form-action : Define which URIs can be used as the action of HTML form elements. sandbox : Specifies an HTML sandbox policy that the user agent applies to the protected resource.
• script-nonce : Define script execution by requiring the presence of the specified nonce on script elements.
• plugin-types : Define the set of plugins that can be invoked by the protected resource by limiting the types of resources that can be embedded.
• reflected-xss : Instructs a user agent to activate or deactivate any heuristics used to filter or block reflected. cross-site scripting attacks, equivalent to the effects of the non-standard X-XSS-Protection header.
• report-uri : Specifies a URI to which the user agent sends reports about policy violation.
• report-to : Defines reporting group to which violation reports ought to be sent.

References:

https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP

https://w3c.github.io/webappsec-csp/

https://www.owasp.org/index.php/Content_Security_Policy