DocumentEditor strict csp "Refused to apply inline styles" errors

Question

Hello, we are currently using the DocumentEditor component in our angular application to render *.rtf documents on a component html page. When developing locally, the component renders the document perfectly fine (formatting and all). When we deploy the angular application to a different environment, where we enable strict CSP rules, the browser dev console show a slew of "Refused to apply inline styles" errors. Our corporate policy has a strict directive to not allow anything "unsafe", both inline and eval. It seems as if the DocumentEditor component is executing scripts to apply dynamic styles to elements which triggers the CSP errors.

We do make use of unique nonce values within our application. Would it be possible to provide the nonce value to the DocumentEditor component at all so we can get around these errors? Is there a feature within the component that alternatively gets around the CSP errors so that they are not violated? This seems like it should be a high priority issue as it violates many corporate directives security-wise.

Ragu Thanigasalam · Answer

Hi Mike,Syncfusion components are
rendered with calculated inline styles and base64 font icons, which are blocked
on a strict CSP-enabled site. To allow them, add the style-src 'self' 'unsafe-inline';and font-src
'self' data:;directives in the meta tag.We have evaluated your query about handling CSP directives, and
we'd like to provide some insights regarding the implementation of Syncfusion
styling. As UI components, our controls are designed to provide a smooth and
seamless user experience, which includes dynamically generating calculated
inline styles for optimal functioning and control over appearance and behavior.Regarding the implementation of nonces with
Syncfusion styling, it's important to note that our components are rendered
with these calculated inline styles directly within our source code.
Unfortunately, at this time, we are restricted to provide nonce support for all
inline styles, including attributes due to performance constraints within our
component architecture. We appreciate your feedback and are
continuously exploring ways to improve security while maintaining the high
performance and functionality of our components.Regards,Ragu T.

Mike Moreno · Answer

That's a little disheartening to hear. The remediation itself isn't that difficult to implement and should not impact performance. I understand that you must maintain the quality level of the UI components. Hopefully, security will be prioritized more in future versions over bells and whistles. In the meantime, we will be discussing lowering our security policies to use the components.

Ragu Thanigasalam · Answer

Mike,To ensure a thorough evaluation, we'll handle this internally as a validation discussion. You can expect an update on our findings by April 23, 2024.Regards,Ragu T.

Bharath Gurumurthy · Answer

Hi Mike Moreno,We understand the importance of addressing inline styling for content security policy compliance.As mentioned earlier, currently, our UI components require dynamic inline style generation from our end to provide you with a seamless, rich appearance and optimal functionality in their current design. It also necessitates an architecture change to provide this support. We want to convey to you that we do not have immediate plans to implement this from our end.We understand the significance of this issue for your content security policy compliance. We are continuously working to improve security concerns to maintain industry standards. While we don't have a specific release number and month to share at the moment, please rest assured that we will keep you updated on any developments.Regards,Bharath.