Content Security Policy (CSP) is an additional layer of security which helps to detect and mitigate certain types of attacks, including Cross Site Scripting (XSS) as well as data injection attacks. These attacks are utilized for everything from the theft of data to site defacement to the distribution of malware.
CSP is built to be fully backward compatible (with the exception of CSP version 2 in which there are multiple explicitly-mentioned inconsistencies in backward compatibility. Browsers that do not support it still function with servers that implement it, and vice-versa: browsers that do not support content security policy simply ignore it, functioning as usual, defaulting to the standard same-origin policy for content on the web, If the site does not offer the CSP header, browsers also use the standard same-origin policy.
In order to enable CSP, you will need to configure your web server to return the Content-Security-Policy HTTP header (sometimes you may see mentions of the X-Content-Security-Policy header, but that is an older version in which you do not need to specify it any longer).
Otherwise, the <meta> element may be used to configure a policy, for instance: <meta http-equiv=”Content-Security-Policy” content=”default-src ‘self’; img-src https://*; child-src ‘none’;”>
Threats
Mitigating cross site scripting
A primary goal of content security policy is to mitigate as well as report XSS attacks. The attacks of this kind exploit the browser’s trust of the content received from the server. Malicious scripts are executed from the victim’s browser due to the browser testing the source of content, even when it is not coming from where it seems to be coming from.
Content security policy makes it possible for server administrators to decrease or eliminate the vectors by which XSS can occur via specifying domains in which the browser should consider to be valid sources of executable scripts. A XCSP compatible browser will then only execute scripts will then only execute scripts that are loaded in source files that have been received from those allowlisted domains, ignoring every other script (this includes inline scripts as well as event-handling HTML attributes).
Sites may opt to globally disallow script execution as an ultimate form of protection that never want to allow scripts to be executed.
Mitigating packet sniffing attacks
In addition to restricting the domains from which content can be loaded, the server is able to specify which protocols are allowed to be utilized, for instance (and ideally, from a security point of view), the server is able to specify that all content must be loaded via HTTPS. A complete data transmission security strategy includes not just the enforcement of HTTPS for data transfer, but also marking all cookies with the secure flag as well as providing automatic redirects from HTTP pages to their HTTPS counterparts. Sites could also utilize the Strict-Transport-Security HTTP header to make sure that browsers connect to them over an encrypted channel only.
Using CSP
Configuring CSP involves adding the content-security-policy HTTP header to a sites page as well as giving it values to control resources the user agent is allowed to load for that particular page. For instance, a page that uploads and displays images may allow images from anywhere, but restrict a form action to a certain endpoint. A correctly designed CSP helps protect a page against a cross site scripting attack.
Specifying your policy
You can use the Content-Security-Policy HTTP header to specify your policy like this example below:
Content-Security-Policy: policy
This particular policy is a string that contains the policy directives explaining your CSP.
Writing a policy
A policy is described by the use of a series of policy directives, each of which explains the policy for a specific resource type or policy area. Your policy should include a default-src policy directive, which is a fallback for other resource types in the case when they are without policies of their own. A policy must include a default-src or script-src directive to stop inline scripts from running, as well as blocking the use of eval(). Included in a policy are default-src or style-src directive in order to restcrit inline styles form being applied from a style attribute or <style> element.
Testing Your Policy
To ease deployment, content security policy can be deployed in report-only mode. The policy is not enforced, however any violations are reported to URI that is provided. Also, a report-only header may be used in order to test a future revision to a policy without even actually deploying the policy itself.
You may use the Content-Security-Policy-Report-Only HTTP header in order to specify your policy like this example below:
Content-Security-Policy-Report-Only: policy
If both a Content-Security-Policy-Report-Only header as well as a Content-Security-Policy header are present inside the same response, the two policies are honored. The policy that is specified in Content-Security-Policy headers is enforced while the Content-Security-Policy-Report-Only policy generates but does not get enforced.
Enabling Reporting
By default, violation reports are not sent. In order to enable violation reporting, you will need to specify the report-uri policy directive, providing one or more URI to which to deliver the reports:
Content-Security-Policy: default-src ‘self’; report-uri http://reportcollector.example.com/collector.cgi
Then you will need to set up your server to receive the reports; it is able to process or store them in whichever manner you feel is suitable.
