axe-core: Axe-core fails under strict content security policy due to eval script (EvalError)
Axe-core script fails under strict content security policy which disallows unsafe eval() executions. The source of the violations is stemming from the doT library and is documented here: https://github.com/olado/doT/issues/276.
The issues can be attributed to two specific areas:
axe.imports['doT'] = function(module, exports, define, require, process) {
var global = Function('return this')();
...
...
_globals = function() {
return this || (0, eval)('this');
}();
...
Mitigating these two areas of the script seems to resolve the issue as demoed under the fixed link below. It seems that this package (doT) is no longer under active development, and the owners do not care for addressing the security violations. It would be advisable to avoid this package altogether, if possible.
- Link to live demo: https://codepen.io/drewlee/full/qJZZbx
- Link to live demo with fix: https://codepen.io/drewlee/full/dgMXRy
axe-core version: 3.1.2About this issue
- Original URL
- State: closed
- Created 6 years ago
- Reactions: 1
- Comments: 15 (6 by maintainers)
Commits related to this issue
- Add unsafe-eval to CSP output for component requests The Axe-core library that govuk_publishing_components uses makes use of a dependency that uses the eval function so this directive is needed until... — committed to alphagov/govuk_publishing_components by kevindew 5 years ago
- Add unsafe-eval to CSP output for component requests The Axe-core library that govuk_publishing_components uses makes use of a dependency that uses the eval function so this directive is needed until... — committed to alphagov/govuk_publishing_components by kevindew 5 years ago
- Add content security policy This adds the GOV.UK security policy to the dummy application of this gem. This means that when using this app in dev or viewing it at https://components.publishing.servic... — committed to alphagov/govuk_publishing_components by kevindew 5 years ago
FYI this is a dupe of https://github.com/dequelabs/react-axe/issues/54 and https://github.com/dequelabs/axe-core/issues/1158
doT is not the only place where eval-likes are being used. I found a usage of
new Functionin audit.js, as per the original issue.To solve this issue, you need to refactor to not use dynamic code generation (e.g. replace things like
new Function('return this')withwindowThe code in audit.js seems tricky to modify and I don’t have enough context to be able to give a recommendation. Ideally, you should refactor the code so that
metadata.messages[prop]is a function to begin with (i.e. by passing the function in, rather than stringified source code). Another option would be to drop that snippet altogether if it’s code to handle a nice-to-have API overload, then deprecate said feature. Another relatively more complex option is do what Angular.js does (implement an interpreter). If the number of possible functions is small, another option would be to write them all out and select the appropriate one via a lookup table.@chandana7393 the pen you used for verification doesn’t actually include the axe-core version that has the CSP fix patch. That was just simply a demo of a suggested fix, using v3.1.2. However, I’ve put up a new pen which includes v3.3.1 and have verified that it resolves the issue. See https://codepen.io/drewlee/full/zgWONO. Thanks everyone for addressing this!
The best we can do for now is to remove all
evals andFunction('')calls in the critical path. Any use of axe-core with custom translations and/or rules will still have theevalproblem until we can remove them in v4.