Content Security Policy (CSP)
Content-Security-Policy is the name of a HTTP response header that modern browsers use to enhance the security of the document (or web page). The Content-Security-Policy header allows you to restrict which resources (such as JavaScript, CSS, Images, etc.) can be loaded, and the URLs that they can be loaded from. Content Security Policy Reference
CSP
Note
As per the above definition and as defined in "3.5. Policy applicability" of the W3C Content Security Policy Level 2 CSP policies are not applied to non content resources such as 'application/json'.
We have received several ITHC reports claiming missing CSP headers on resource types, such as 'application/json' that are not in scope of the policy.
Despite this - we have set a CSP policy on our API calls of 'default-src: 'none'' as a "Belt and Braces" approach.
CSP Settings
| Directive | Values Used | Purpose / Reason |
|---|---|---|
| base-uri | Set to 'self'. | Restricts the URLs that can be used in a <base> element. This is set in platform UI - <base href="~/" /> |
| connect-src | Set to allow:
|
Controls destinations for XHR, Fetch, WebSockets, EventSource connections. |
| child-src | Not Set. Falls back to the default-src directive. | |
| default-src | 'none' | Fallback for all resource types. This is the most restrictive setting |
| fenced-frame-src | Not set (experimental). The user agent will look for the frame-src directive (which falls back to the child-src directive). | valid sources for nested browsing contexts loaded into <fencedframe> elements. |
| font-src style-src img-src |
'self', sha's and managed resource urls | Mitigates injection attacks. |
| form-action | For the UI portals this is set to 'self'. The identity login page adds the urls fo the third party authentication providers defined. | Limits where forms can submit data. |
| frame-ancestors | Set to 'self' as a belt and braces measure | Controls which sites can embed the page in a frame or iframe. We are setting the X-Frame-Options header to SAMEORIGIN which is the equivalent of 'self' but has better support in older browsers. |
| frame-src | Not set. The user agent will look for the child-src directive (which falls back to the default-src directive). | Controls which sources can be embedded in <iframe> or <frame>. |
| manifest-src | Not Set. Falls back to the default-src directive. | Specifies valid sources for web app manifests. |
| media-src | Not set. Defaults to default-src. | Controls audio and video sources (HTML5 <audio> and <video>). |
| object-src | Not set. Defaults to default-src | Specifies valid sources for <object>, <embed>, <applet>; should typically be 'none' to block plugins. |
| script-src | 'self', a nonce for inline script, sha's and managed resource urls and logging urls as required | Restricts where scripts can be loaded from; helps prevent XSS. |
| script-src-elem | Not set. Falls back to script-src | specifies valid sources for script elements (<script>). |
| script-src-attribute | Not set. Falls back to script-src | specifies valid sources for inline script event handlers. |
| worker-src | Not set. The user agent will first look for the child-src directive, then the script-src directive, then finally for the default-src directive, when governing worker execution. In our case, the script-src as above. | Restricts sources for Web Workers and Service Workers. |
| prefetch-src | Depreciated - should not be used Not Set. Falls back to the default-src directive. | Controls which sources can be prefetched or preloaded. |
| sandbox | Not set. This header is generally used to further restrict (sandbox) iframes - which are not used. Top level page is managed by standard settings herein. Applying sandbox would be destructive to these settings. | Applies a sandbox to the page with optional flags; reduces page capabilities. |
| upgrade-insecure-requests | Not set. This directive is intended for websites with large numbers of insecure legacy URLs that need to be rewritten. | Forces all HTTP requests to be upgraded to HTTPS. |
| block-all-mixed-content | Depreciated - should not be used | Blocks all mixed (HTTP over HTTPS) content. |
| require-trusted-types-for | Not used. | Enforces Trusted Types for scripts to mitigate DOM XSS. |
| trusted-types | Not used. | Defines allowed Trusted Types policies. |
| report-to | Set to reporting url. | Specifies a reporting group (defined in a separate Report-To header) for CSP violation reports. |
| report-uri | Although depreciated some browsers are still supporting it and do not yet support report-to. We set both |
Depreciated or policies that should not be set
These settings should not be set as they are depreciated
| Directive | Purpose / Reason |
|---|---|
| block-all-mixed-content | Depreciated - should not be used |
| referrer | Depreciated and not supported by many browsers. We use the Referrer-Policy header instead |
| reflected-xss | Removed from the specification in 2015. X-XSS-Protection offered the same protection but this itself is now depreciated. The HTTP X-XSS-Protection response header was a feature of Internet Explorer, Chrome and Safari that stopped pages from loading when they detected reflected cross-site scripting (XSS) attacks. These protections are largely unnecessary in modern browsers when sites implement a strong Content-Security-Policy that disables the use of inline JavaScript ('unsafe-inline'). X-XSS-Protection header |
| plugin-types | Not in standard. We believe this had vulnerabilities. |