I would like to use Content Security Policy for my JSF 2.1 based Web projects as I think it could improve protection against XSS attacks significantly.
Due to CSP\'s
You could avoid using the unsafe-inline
source-expression in order to whitelist inline <script>
s, by utilizing nonce and/or hash instead [1]. Doing so would require:
Inclusion of a nonce
attribute in inline <script>
elements, e.g.
<f:ajax ... pt:nonce="$placeHolder" />
(assuming that the pt
prefix has been bound to the http://xmlns.jcp.org/jsf/passthrough
namespace). The attribute's value could just be a placeholder within the view file, enabling you to replace it collectively in all trusted inline <script>
s later on.
Replacement (via a Filter
, for instance) of the placeholder with a random value in each response and insertion of that value into the CSP HTTP Header and/or equivalent <meta>
element, producing for example
<script ... nonce="126cfb...">
and
Content-Security-Policy: default-src 'self'; ... script-src 'self' 'nonce-126cfb...'
.
Theoretically, produced nonce-values should also be stored on the server, to avoid their reassignment in the near future, since they're supposed to be unique.
Additionally or alternatively, insertion of each trusted inline <script>
contents' digest into the CSP HTTP Header and/or equivalent <meta>
element, alongside its respective hash-algo, such as
Content-Security-Policy: script-src 'sha256-126cfb...='
.
hash-values should too be regenerated while preparing each response, I guess, since <script>
s are generally expected to change over time and with JSF you might not immediately notice when they do.