content security policy
content security policy
Introduced in November 2012, Content Security Policy presents an extra layer of security against multiple vulnerabilities such as XSS, Clickjacking, Protocol Downgrading and Frame Injection. It appears that CSP will become the most significant tool for client side security in the near future, since it provides a substitute for security headers, such as X-Frame-Options and X-XSS-Protection, that aren’t enabled by default.
Here is a sample CSP header:
In CSP, we use a whitelist to define rules. With this approach, we can filter out any resources that do not fit with our rules. All we have to do is to state the resources within the Content-Security-Policy response header:
This CSP directive allows script loading only over our domain and https://apis.google.com. Any other inline scripts will not run.
Content Security Policy Directives
Along with the CSP header, we can use the following directives to further limit and define the use of resources.
default-src Directive Example
By default these directives are unrestrictive, meaning that if they are not declared in the CSP header, any request will go through. So, if no value is given for style-src, this will be interpreted as style-src: * and styles from all sources will be allowed.
We can use the default-src directive to change this. The specified value will override most directives ending with -src by setting a default value for them. If we define default-src as http://www.example.com and don’t set a value for font-src, the fonts can only be loaded from https://www.example.com.
However, default-src cannot override these directives:
- base-uri
- form-action
- frame-ancestors
- plugin-types
- report-uri
- sandbox
We can add more than one directive in one HTTP header by separating them with a semicolon:
Multiple values for a directive must be separated with a space:
One Thing To Keep in Mind When Using Content Security Policy
Define CSP for each page set in the HTTP response. This will help you define the optimal policy for each page and its specific needs.
You can learn more about Content-Security-Policy (CSP) on the Netsparker Blog.
|
Directive |
Description |
|
base-uri: |
The base HTML element contains the absolute URL that is prepended to all the relative URLs on the page. This directive helps us restrict the URLs that are allowed to be used in the base HTML element, and therefore prevent Base Tag Hijacking attacks. |
|
child-src: |
This directive allows us to define which websites are permitted to be loaded in frames located on the page. We can use it as an extra precaution to protect our page from Frame Injection attacks. |
|
connect-src: |
This directive restricts the resources that can be loaded via script interfaces such as XHR or WebSockets. This prevents attackers from stealing data from the site. |
|
font-src: |
This directive specifies the font sources that can be loaded using @font-face. It is mostly used to prevent attackers from sending extracted data back to their server using the @font-face src directive. |
|
form-action: |
This directive specifies the URLs that can be used as targets for form submissions. It can be used as an extra precaution to protect pages from Form Tag Hijacking and Cross-Site Scripting attacks. |
|
frame-ancestors: |
This directive specifies the sites that have the authority to load the current page in a frame, iframe, object, embed, and applet tag. It is a substitute for X-Frame-Options, since it can also help prevent Clickjacking and UI Redressing attacks. |
|
img-src: |
This directive defines the sources from which images can be loaded. |
|
media-src: |
This directive defines or restricts the sources from which video and audio can be loaded. |
|
object-src: |
This directive defines or restricts the sources from |
|
plugin-types: |
This directive defines or restricts the plugin types that can be loaded. |
|
report-uri: |
This directive specifies the URLs that will receive the report when a CSP directive is violated. |
|
style-src: |
This directive defines or restricts the sources for CSS files. This allows you to avoid data exfiltration via CSS. |
|
upgrade-insecure-requests: |
This directive converts the HTTP requests to HTTPS. |
