Content Security Policy (CSP) is a security header that assists in identifying and mitigating several types of attacks, including Cross Site Scripting (XSS), clickjacking and data injection attacks. These attacks are utilized for everything from stealing of data or site defacement to spreading of malware.
CSP is compatible with browsers that don’t even support CSP and will still work with servers that have implemented it, and vice-versa. Browsers that don’t support CSP will neglect it, operating as usual, and defaulting to the standard same-origin policy for web content.
By using proper CSP directives in HTTP response headers, you can selectively define which data sources should be allowed in your web application.
Why Content Security Policy?
Web security is based on same-origin policy (SOP), which blocks a website from accessing data outside its origin. This should be enough to ensure security, but the modern web demands sites to incorporate many assets from outside sources like scripts, fonts, styles, and other resources from content delivery networks, etc.
Hackers utilize cross-site scripting (XSS) attacks to deceive websites trusted by the user into delivering malicious code. Without any extra security measures, the browser will execute all code from any origin and will not be able to determine which code is authorized.
Content Security Policy (CSP) has a standardized collection of directives that instruct the browser which content sources can be trusted and which should be prevented. Using precisely defined policies, you can define browser content to eliminate many common injection vectors and significantly reduce the risk of XSS attacks.
Using Content Security Policy and Directives
Implementing Content Security Policy involves adding the Content-Security-Policy HTTP header to every response from the server, thus providing the web page values to manage the resources the user agent is allowed to use.
CSP allows to define various content restrictions using CSP directives.
Content-Security-Policy: default-src 'self'; img-src *; script-src beaglescripts.com;
Given above is the CSP of a website that displays images. From this, we can observe that default-src, img-src and script-src are the directives.
Listed below are a couple of CSP directives and their use cases:
Default-src: This directive serves as a fallback for the other CSP fetch directives. For absent directives like media-src and script-src, the user agent looks for the default-src directive’s content and uses it.
Script-src: This directive is used to define locations from which external scripts can be loaded.
Img-src: Specifies sources from which images can be retrieved.
Media-src: This directive is used to define locations from which rich media like video can be retrieved.
Object-src: This directive is used to define locations from which plugins can be retrieved.
Font-src: Specifies permitted sources for loading fonts.
You can find a more updated and complete list maintained by Mozilla here.
Another way is to set a policy on a page directly in the markup. We can do that by using a <meta> tag with http-equiv attribute:
<meta http-equiv="Content-Security-Policy" content="policy">
Use Cases of Content Security Policy with Examples
Use case 1
Content-Security-Policy: default-src 'self' *.beaglesecurity.com;
In the above given policy, the default-src directive is set to itself, beaglesecurity.com, and all of its subdomains. This allows the application to load content from beaglesecurity.com and any subdomain under beaglesecurity.com.
Since the content to be loaded from beaglesecurity.com is not mentioned specifically in the policy, default-src will allow all content from javascript to style and media.
Use case 2
Content-Security-Policy: default-src 'self'; img-src *;
In the above given policy, the default-src directive is set to itself, and the img-src directive is set to all (value is set to wildcard), which allows the application to load images from any domain, but won’t allow any other content.
Use case 3
Content-Security-Policy: default-src 'self'; img-src *; media-src beaglemedia.com beaglevideo.com; script-src beaglescripts.com;
Like the other use cases:
img-src directive allows images to load from anywhere.
media-src directive only allows to load media from beaglemedia.com and beaglevideo.com.
script-src directive only allows to load executable script from beaglescripts.com.
Reporting and Testing
By default, violation reports aren’t kept or forwarded. To allow reporting, we need to define the report-uri directive and provide at least one URI to deliver the reports as shown below.
Content-Security-Policy: default-src 'self'; report-uri https://report.beaglesecurity.com/cspviolation;
The server has to be configured in a way to store the report or process it by any means.
Likewise, for testing, we can use the Content-Security-Policy-Report-Only header in the server.
Content-Security-Policy-Report-Only: default-src 'self'; report-uri https://report.beaglesecurity.com/testcspviolation;
If both the Content-Security-Policy-Report-Only header and Content-Security-Policy header are present in the same server response, both the policies are accepted.
The policy specified in Content-Security-Policy headers is enforced while the Content-Security-Policy-Report-Only policy generates reports and pushes them to the report URI but is not enforced mandatorily.
Content-Security-Policy: default-src 'self'; style-src style.beaglesecurity.com; report-uri https://report.beaglesecurity.com/cspviolation;
For the above given policy, if the application tries to load a stylesheet from any domain other than self or style.beaglesecurity.com, a violation report is triggered and forwarded to the URI provided.
CSP violation report is generated in JSON format. A report generated by the above policy violation would look something like this.
Content-Security-Policy: default-src 'self'; style-src style.beaglesecurity.com; report-uri https://report.beaglesecurity.com/cspviolation;
For the above given policy, if the application tries to load a stylesheet from any domain other than self or style.beaglesecurity.com, a violation report is triggered and forwarded to the URI provided.
CSP violation report is generated in JSON format. A report generated by the above policy violation would look something like this.
{
"csp-report": {
"document-uri": "https://beaglesecurity.com/home.html",
"referrer": "",
"blocked-uri": "https://testing.com/css/style.css",
"violated-directive": "style-src style.beaglesecurity.com",
"original-policy": "default-src 'self'; style-src style.beaglesecurity.com; report-uri https://report.beaglesecurity.com/cspviolation"
}
}
Conclusion
CSP is compatible with almost all modern browsers and it is extensively used across the web as an efficient mechanism in reducing the risk of cross site scripting attacks. Implementing CSP will act as an extra layer of security for your web application.
You can also refer to our detailed guide on implementation of CSP and other security headers on commonly used servers like Nginx, Apache and IIS.
You can test your application’s Content Security Policy using Beagle Security. Beagle Security analyzes your application’s policy and provides a detailed report. Beagle Security checks if the policy directives are using correct syntax. There are also multiple test cases to check if the directive values are used effectively to give the expected level of protection.
In addition, Beagle Security checks for all security headers and other 2000+ vulnerabilities in a web application.
