Content Security Policy¶
Overview¶
This section describes the handling of a Content Security Policy (CSP), a standard that is introduced to prevent cross-site scripting (XSS), the execution of malicious content and code or clickjacking, within the context of a website. This prevention is achieved by restricting the sources of content loaded by the user agent or browser to only a list of the allowed ones by the site operator.
Those aforementioned restrictions are implemented by headers that are sent with the server response. The Content Security Policy header is managed and sent by the Gateway. The Content Security Policy is standardized by the W3C. The Level 2 version is available as a W3C Recommendation and Level 3 as a W3C Working Draft.
Why should you use it?¶
CSP helps mitigate possible attacks and various cross-site scripting vulnerabilities. However, you must secure your application against such attacks on multiple levels, as you cannot rely solely on CSP. The following list describes common scenarios for CSP:
- Prevent direct dynamic code evaluation by disabling
eval. Under certain circumstances,evalcan also be useful, but we always recommend using Function objects to create dynamically executed code (see also the OWASP Article). - Prevent certain image sources that can leak sensitive information, like CRSF tokens (see GitHub's post-CSP journey for more details and examples).
- Restrict browsers to only load resources from trusted origins and prevent, for example, the web page from being embedded into iframes or completely preventing iframes.
Finally, we advise reading the MDN Content Security Policy documentation to get detailed explanations for possible configurations. Read the Configuring Content Security Policy to learn how to configure the Content Security Policy for your application.
Defaults and Recommendations¶
We recommend using a whitelisting approach and a very strict policy that replaces the default one. Consequently, you must define a list of allowed origins for all types of content and resources that are used by your website. Although it might be feasible to start with a blacklisting approach to avoid breaking your website.
During the creation of an application in the Developer Cockpit, a default header for the Content Security Policy will be set with the following value:
Content-Security-Policy: default-src 'self' static.{env}.{mindsphere-domain}; style-src * 'unsafe-inline'; script-src 'self' 'unsafe-inline' static.{env}.{mindsphere-domain}; img-src * data:;
The table below explains the individual configuration items, whereas {env} and {mindsphere-domain} are used for the region and domain. For example, eu1.mindsphere.io:
| Directive | Value | Description |
|---|---|---|
default-src | 'self' static.{env}.{mindsphere-domain} | By default, for every directive (if not overridden), we only allow loading content from its own origin or static files from {mindsphere-domain}. |
script-src | 'self' 'unsafe-inline' static.{env}.{mindsphere-domain} | Allows to load scripts from the same origin, Insights Hub static files and allows to execute scripts in <script>...</script> tags. We recommend using a more strict configuration. |
style-src | * 'unsafe-inline' | Allows to load style sheets from all origins and inline style attributes. We recommend restricting those settings. |
img-src | * data: | Allows to load images from all origins and use data schemes in style sheets and tags, for example, BASE64 encoded images. |
Additionally, we recommend defining rules for those additional content types:
| Directive | Example Value | Description |
|---|---|---|
child-src | self | Defines valid origins for loading frames. This directive is preferred over the outdated frame-src directive. |
connect-src | self | Defines valid origins for executing AJAX, WebSocket or EvenSource requests. You need to change those if you want to call external APIs. |
font-src | self | Defines valid origins for fonts. |
form-action | self | Defines valid origins that can be used as <form>...</form> actions. |
Web Frameworks and Webpack¶
The usage of the JavaScript eval() is not recommended as it executes passed code with the privileges of the caller and has a bad performance. Under certain conditions, a malicious party might end up running code on the user's machine, which can lead to attacks. Modern JavaScript engines also support the creation of Function objects that do not suffer from security and performance problems.
However, popular frameworks like angular or vue.js are still using eval mostly due to the underlying web bundler webpack. During the compilation or bundling of an application, webpack is often used to transpile modern JavaScript or TypeScript to support multiple browsers and browser versions. Sourcemaps are generated, containing a mapping between the transpiled and original code, to facilitate the debugging of the web application. webpack exposes different ways of generating those sourcemaps and an often chosen style is cheap-eval-source-map. While this is acceptable for local development, it presents a problem in production environments, as explained in the previous section.
The current default policy forces you to choose a different style of source mapping to avoid any problems. You can find alternatives in the official webpack documentation for the devtool configuration. Frameworks like angular also expose configuration parameters for those source mapping styles.
Related Links¶
- CSP Level 2 Recommendation
- CSP Level 3 Working Draft
- Function objects
- GitHub's post-CSP journey
- Configuring Content Security Policy
- MDN Content Security Policy
- Mozilla - Implementing Content Security Policy
Except where otherwise noted, content on this site is licensed under the Development License Agreement.