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 default behaviour to block all inline JavaScript it basically breaks JSF's
<f:ajax execute="input" render="output" />
functionality. This is because JSF generates lots of inline JavaScript code when using the above stated construct.
Does anybody know if there is a way to use CSP in JSF based projects which make use of f:ajax without the need to allow inline JS by using the following CSP directive:
Content-Security-Policy: default-src 'self'; script-src 'self' 'unsafe-inline'
I know that manually placing all of the JavaScript in a separate file would be possible, but doing so I would be forced to do all the Ajax stuff manually.
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.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With