Content Security Policy on MindSphere¶
This section describes the handling of Content Security Policy (CSP) within MindSphere. Content Security Policy is a standard that has been introduced to prevent cross-site-scripting (XSS), execution of malicious content and code, or clickjacking within the context on a website. This prevention is achieved by restricting the sources of content loaded by the user agent / browser to only a list of the allowed ones of the site operator.
Those aforementioned restrictions are implemented by headers that are sent with the server response. Within the MindSphere platform the Content Security Policy header is managed and sent by the MindSphere Gateway. 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 mitigating possible attacks and various cross-site-scripting vulnerabilities. Nevertheless, you must secure your application against such attacks on multiple levels as you cannot rely only on it. The following list describes common scenarios for CSP:
- Prevent direct dynamic code evaluation by disabling
eval. Under certain circumstances
evalcan be also useful, but we always recommend to use Function objects to create dynamically executed code (see also 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 of being embedded into iframes or completely preventing iframes.
Finally, we advise to read 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 & Recommendations¶
We recommend to use a whitelisting approach and to use 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 MindSphere Developer Cockpit a default header for the Content Security Policy is set with the following value:
Content-Security-Policy: default-src 'self' static.<env>.mindsphere.io; style-src * 'unsafe-inline'; script-src 'self' 'unsafe-inline' static.<env>.mindsphere.io; img-src * data:;
The table below explains the individual configuration items whereas
<env> is used for the region, e.g.
||By default for every directive (if not overridden) we only allow loading content from the own origin or static files from MindSphere.io.|
||Allows to load scripts from the same origin, MindSphere static files and allows to execute scripts in
||Allows to load style sheets from all origins and inline style attributes. We recommend to restrict those settings.|
||Allows to load images from all origins and to use data schemes in style sheets and in tags, e.g. BASE64 encoded images.|
In addition, we recommend to define rules for those additional content types:
||Defines valid origins for loading frames. This directive is preferred over the outdated
||Defines valid origins executing AJAX, WebSocket or EvenSource requests. You need to change those if you want to call external APIs.|
||Defines valid origins for fonts.|
||Defines valid origins that can be used as
Web Frameworks & Webpack¶
eval() is not recommended as it executes passed code with the privileges of the caller and has bad performance.
Under certain conditions a malicious party might end up running code on the user's machine which can lead to attacks.
Nevertheless, popular frameworks like angular or vue.js are still using
eval mostly due to the underlying web bundler webpack.
So called sourcemaps are emitted that contain a mapping between the transpiled and original code to allow debugging of the web application.
webpack exposes different ways of generating those sourcemaps and an often chosen style is
While this is fine for local development, it poses a problem in production environments as outlined in the previous section.
The current default policy forces you to choose a different style of source mapping to avoid any problems on the MindSphere platform. 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 as well.
- 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
Any questions left?
Except where otherwise noted, content on this site is licensed under the MindSphere Development License Agreement.