[
https://issues.apache.org/jira/browse/WICKET-6703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16939896#comment-16939896
]
Andrew Kondratev edited comment on WICKET-6703 at 9/28/19 8:28 AM:
-------------------------------------------------------------------
[~svenmeier] this one is certainly less powerful than removing unsafe-eval.
Google CSP evaluator marks unsafe-inline as "High severity finding" whereas the
unsafe-eval as "Possible medium severity finding", however it's a security
feature and it was invented for a reason, so it's good to have it available.
Also I have more serious argument: some our huge clients from education in US
want us "to take measures to improve the CSP posture", even bigger governmental
client from Australia gave us very short period to eliminate unsafe-inline and
a year to get rid of unsafe-inline. I suspect, many Wicket developers work in
corporate and enterprise sector and are very likely to experience the same.
This is potentially slower than execution of predefined function (which Wicket
anyway doesn't do):
{{Execute with dom total, ms 786}}
Execute with dom average, ms 0.0786
Execute without dom total, ms 87
Execute without dom average, ms 0.0087
However as yourself demonstrated it's not a way slower than the eval currently
used:
Execute with dom total, ms 2102
Execute with dom average, ms 0.2102
Execute without dom total (eval), ms 1176
Execute without dom average (eval), ms 0.1176
I suppose it's insignificant, considering that most of the time spend on wicket
ajax request is a network latency and DOM manipulation.
was (Author: kondratev):
[~svenmeier] this one is certainly less powerful than removing unsafe-eval.
Google CSP evaluator marks unsafe-inline as "High severity finding" whereas the
unsafe-eval as "Possible medium severity finding", however it's a security
feature and it was invented for a reason, so it's good to have it available.
Also I have more serious argument: some our huge clients from education in US
want us "to take measures to improve the CSP posture", even bigger governmental
client from Australia gave us very short period to eliminate unsafe-inline and
a year to get rid of unsafe-inline. I suspect, many Wicket developers work in
corporate and enterprise sector and are very likely to experience the same.
This is potentially slower than execution of predefined function (which Wicket
anyway doesn't do)
{{Execute with dom total, ms 786}}
{{Execute with dom average, ms 0.0786Execute without dom total, ms 87
Execute without dom average, ms 0.0087}}
> Eliminate window.eval from wicket-ajax-jquery
> ---------------------------------------------
>
> Key: WICKET-6703
> URL: https://issues.apache.org/jira/browse/WICKET-6703
> Project: Wicket
> Issue Type: Improvement
> Components: wicket-core
> Reporter: Andrew Kondratev
> Assignee: Sven Meier
> Priority: Major
>
> It's impossible to configure wicket with strict CSP Policy without
> unsafe-eval and keep using AJAX, because most of AJAX responses contain
> evaluations and header contributions which cause window.eval to be called.
> Window eval can be replaced with DOMEval with nonce approach. DOM eval is
> available in jQuery as globalEval.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
