Mircea Toma added a comment - 14/Apr/22 10:20 AM - edited The research for CSP level 2 support in ICEfaces shows that the core and its components are fundamentally not suited for a strict CSP implementation. There are various reasons which are described below: ICEfaces core and components use inline JS event handlers (such as onclick , onkeypress ...), for them to work unsafe-hashes policy needs to be used (see https://content-security-policy.com/unsafe-hashes/ ) together with the corresponding calculated hashes. This approach already makes the CSP security less strict. Hashes for inline code and inline event handlers can be calculated easily by ICEfaces core and sent during page load. The problem is that ICEfaces will subsequently partially update the page and introduce new inline code and inline event handlers. Sending these new hashes over AJAX responses does not make the browser take them into account as additional CSP policy. CSP level 3 introduces strict-dynamic policy that can help with subsequently loaded inline code (by previously secured code) but the policy works only with inline code that was not introduced by the markup parser. Unfortunately Mojarra, Myfaces, ICEfaces core and ICEfaces components use HtmlElement.innerHTML property to parse markup and evaluate inline code. Also CSP level 3 is just in draft phase and just partially implemented by browsers. Although CSP level 2 support is not possible ICEfaces uses alternative mechanisms to combat XSS (Cross-site Scripting): Parameters used by JSF and ICEfaces core are validated to ensure their values don't contain rogue code. ICEfaces output components (server side) escape the rendered text thus avoiding the evaluation any inline markup or code. See the list of fixes made against XSS: http://jira.icesoft.org/browse/ICE-2184?jql=status%20in%20(Resolved%2C%20Closed%2C%20Done)%20AND%20text%20~%20%22cross-site%22