Check Content Security Policies

To enhance effective security controls available to the web browser and help prevent client-side attacks, such as Cross-Site Scripting, Content Security Policies have been configured by default for WorkZone Client and WorkZone Configurator.

A correctly configured Content Security Policy response header enables WorkZone Clientor WorkZone Configurator to define which content sources the browser may load. A strict policy can help mitigate the risk of various content injection vulnerabilities, including XSS and click-jacking attacks and help prevent an attacker from inserting crafted content, such as malicious JavaScript or CSS, which could result in XSS or CSS injection attacks.

While a correctly configured Content Security Policy can help mitigate the risk associated with injection attacks, it should be considered a defense-in-depth measure for injection attacks, as it is dependent on browser support.

Default WorkZone Client policy

The default WorkZone Client Content Security Policy is:

default-src data: *; frame-src blob: ms-access: ms-infopath: ms-project: ms-publisher: ms-visio: ms-word: ms-powerpoint: ms-excel: *; script-src 'self' 'unsafe-eval' 'unsafe-inline' blob:; connect-src *; img-src 'self' data:; style-src 'self' 'unsafe-inline'; frame-ancestors 'self';

Default WorkZone Configurator policy

The default WorkZone Configurator Content Security Policy is:

default-src 'self'; font-src 'self' data:; script-src 'self' 'unsafe-eval'; connect-src 'self'; img-src 'self' data:; style-src 'self' 'unsafe-inline'; frame-ancestors 'self';

Troubleshooting issues

If your organization experiences connectivity issues or issues with the execution of scripts or other code snippets in browsers accessing WorkZone Client and WorkZone Configurator, these issues might be attributed the default Content Security Policy values.

You can check the default Content Security Policies on the Microsoft IIS 7 server in the IIS Manager form to see if the policy performs as expected and adjust the policy values if necessary.

You can also check the Content Security Policy settings by using the developer tools in the relevant browser or by using 3rd party development tools – for example Postman (a platform for API development).

Configure a Content Security Policy

Content Security Policies can be inspected and configured on a Microsoft IIS 7 server in the IIS Manager form:

  1. On the Microsoft IIS 7 server, open the IIS Manager form.
  2. In the IIS Manager form > Features View, select HTTP Response Headers to open the HTTP Response Headers page.
  3. On the HTTP Response Headers page > Actions pane, click Add to open the Add Custom HTTP Response Header form.
  4. In the Add Custom HTTP Response Header form > Name field, enter a name for your Content Security Policy, for example Content-Security-Policy.
  5. In the Add Custom HTTP Response Header form > Value field, configure the policy you want to apply.
  6. Click OK to save your policy

Important notes regarding the Content Security Policy

A Content Security Policy header allows you to define approved sources for content that the browser can load. By specifying only those sources that you wish the browser to load content from, you can help prevent loading malevolent or harmful content that may have been placed on the site or page.

A Content Security Policy header is only enforced per page. The browser will not cache a Content Security Policy header and continue to enforce the policy. You must send the Content Security Policy header with every response you want the policy to be enforced on.

Browser support

The Content-Security-Policy header is supported in all latest versions of Chrome, Edge, FireFox, Safari (OSX and iOS), Opera (but not Mini), Android Browser and Chrome for Android.

The Internet Explorer browser requires the X-Content-Security-Policy header instead so you must issue the header twice if you want to have the most widespread support for the Content Security Policy header.

Test the Policy

After you have configured the Content Security Policy, you can test the policy by sending the header Content-Security-Policy-Report-Only: instead of the Content-Security-Policy: header.

Your browser will still receive and act upon the configured policy, but the browser will display a list of the expected effects of the defined policy.