A Content Security Policy, commonly known as CSP, acts as a set of directives that helps protect our web application—think of it as a security guard for our online presence. It's a part of our defense-in-depth strategy against various cyber threats, such as XSS, clickjacking and injection attacks. By implementing a stronger CSP, we're investing in additional security measures to protect our web applications.
Two of our target CSP directives to remove are unsafe-eval and unsafe-inline. The usage of these is common in both web applications and customizations/plugins across the software industry. As the industry works to default to stronger CSP, some changes may be required. For instance, if your custom scripts were previously added directly into web pages (inline) or if they included dynamic code execution (eval), these practices will no longer be permitted under the new policy. This means that you may need to modify how your custom content or customizations are applied.
Strategy Product CSP Plan:
To minimize impact to customizations and integrations, making the stronger CSP policies optional. This will enable customers who are ready to adopt them and for those who aren’t ready to opt-out while they test out and identify any potential impact.
Areas of Strategy's Platform which may be impacted:
A few areas of Strategy can be configured or accept custom content and could be impacted. These include:
Strategy Library CSP:
Strategy Library has removed unsafe-eval from its CSP directives by default. Environments with failing executions of the eval JavaScript function may opt-out following the steps in the FAQ below.
CSP Directive | Impact | Default enforced as of: |
|---|---|---|
unsafe-eval | JavaScript based plugins, visualizations or customizations which use eval will break. | End of 2024 |
Strategy Web Opt-In CSP:
Strategy is planning to remove unsafe-inline and unsafe-eval from Strategy Web’s CSP Policy in a phased approach:
CSP Directive | Impact | Default enforced as of: |
|---|---|---|
unsafe-eval | JavaScript based plugins, visualizations or customizations which use eval will likely break. | June 2025 |
unsafe-inline | JavaScript based plugins, visualizations or customizations which use inline will likely break. | Not yet announced. |
FAQ:
Add the following three lines in the config override configuration file:
The file path is: tomcat/webapps/<WebApplication>/WEB-INF/classes/config. The file name is: configOverride.properties
Customizations that do not use removed directives are not affected. Be sure to check for usage of removed directives in customized HTML, HTML containers or any third-party libraries that are used. A functional end-to-end test is recommended to certify that a customization will execute properly in the browser when restricted calls are not allowed.
Historically, eval is used in web applications to parse JSON data, create functions on the fly, or to load dynamic code. Replace eval depending on the situation. For example, use JSON.parse()to parse JSON data. Use JavaScript source code downloaded from your web application instead of loading dynamic code on the client.
Strategy professional services can be contracted to help secure your custom capabilities. Please contact your account team or Strategy Technical Support to learn more about how we can help.
Updates: