Skip to content

Content Security Policy


This section describes the handling of Content Security Policy (CSP), 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. The Content Security Policy header is managed and sent by the 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 eval can 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 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-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, e.g.

Directive Value Description
default-src 'self' static.{env}.{mindsphere-domain} By default for every directive (if not overridden) we only allow loading content from the 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 to use a more strict configuration.
style-src * 'unsafe-inline' Allows to load style sheets from all origins and inline style attributes. We recommend to restrict those settings.
img-src * data: 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:

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 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 & Webpack

The usage of the JavaScript 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. Modern JavaScript engines also support the creation of Function objects that do not suffer from security and performance problems.

Nevertheless, popular frameworks like angular or vue.js are still using eval mostly due to the underlying web bundler webpack. During the compilation / bundling of an application webpack is often used to transpile modern JavaScript or TypeScript to support multiple browsers and browser versions. 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 cheap-eval-source-map. 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. 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.

Last update: October 26, 2023

Except where otherwise noted, content on this site is licensed under the Development License Agreement.