[Content Security Poilicy] Filtering in x-data-grid broken after update to v6.10.1 due to eval

[superkartoffel]

Steps to reproduce 🕹

Steps:

1. update your project to latest v6.10.1
2. set content-security-policy header to include script-src: "'self'"
3. open your application and try to use filter

Current behavior 😯

filters are not applied and console shows errors that eval expressions have been blocked due to content-security-policy.

Expected behavior 🤔

filters should work without having to enable unsafe-eval CSP header.

Context 🔦

I report this as a bug, since I consider it a breaking change in a patch version update. The same content-security-policy works fine with v6.10.0

The change has most likely been introduced in #9635 and can easily be worked around by including content-security-policy header script-src: 'unsafe-eval'. But I do not consider it safe to do so.

Hence my question: Is there another way of enabling eval expressions just for this script instead of globally?
Also, please update you changelog to warn others about this change.

A bit related to:

• [CSP] Issue with inline-style and Content Security Policy material-ui#19938
• [CSP] Blocks data-emotion inline styles material-ui#36095

Your environment 🌎

Firefox and chrome are affected, I did not test any other browser.

Order ID or Support key 💳 (optional)

No response

[m4theushw]

@romgrk How about making the use of eval opt-in?

[cherniavskii]

Yeah, I totally forgot that eval might be a problem for CSP 🙃

[peterhirn]

eval usage also adds 300KB to my bundle size using Vite.

WARN ../../.yarn/virtual/@mui-x-data-grid-virtual-e60fa12330/0/cache/@mui-x-data-grid-npm-6.10.1-a169528a91-7ae6335b82.zip/node_modules/@mui/x-data-grid/hooks/features/filter/gridFilterUtils.js (171:21) Use of eval in "../../.yarn/virtual/@mui-x-data-grid-virtual-e60fa12330/0/cache/@mui-x-data-grid-npm-6.10.1-a169528a91-7ae6335b82.zip/node_modules/@mui/x-data-grid/hooks/features/filter/gridFilterUtils.js" is strongly discouraged as it poses security risks and may cause issues with minification.

[romgrk]

I'll check if we can feature-detect eval at runtime.

@peterhirn 300KB seems excessive for what we do with eval, are you sure about those numbers? Could it be a bundler issue?

[peterhirn]

Yes, I'm sure. Changing "@mui/x-data-grid": "6.10.0" to "@mui/x-data-grid": "6.10.1" adds an additional 314.8 kb and outputs the following warning:

WARN ../../.yarn/virtual/@mui-x-data-grid-virtual-e60fa12330/0/cache/@mui-x-data-grid-npm-6.10.1-a169528a91-7ae6335b82.zip/node_modules/@mui/x-data-grid/hooks/features/filter/gridFilterUtils.js (171:21) Use of eval in "../../.yarn/virtual/@mui-x-data-grid-virtual-e60fa12330/0/cache/@mui-x-data-grid-npm-6.10.1-a169528a91-7ae6335b82.zip/node_modules/@mui/x-data-grid/hooks/features/filter/gridFilterUtils.js" is strongly discouraged as it poses security risks and may cause issues with minification.

I don't feel like creating a minimal reproduction of this issue. Project setup: yarn (Plug'n'Play), vite, react, mui (all latest version).

[romgrk]

Size at 6.10.0: 406.1kb
Size at 6.10.1: 417.5kb

I'm not sure what's going on with your bundle but there might be an issue there. I would open an issue in your bundler's repo so we can get some assistance from the maintainers there, it will be easier to figure out.

[oliviertassinari]

eval usage also adds a cool 300KB to my bundle size using vite.

@peterhirn I had a quick look. It seems to be because Terser (used by Vite) can no longer minify function names as eval() has global scope access. I got this lead from terser/terser#455. It's referenced in https://rollupjs.org/troubleshooting/#avoiding-eval too and terser seems to have an option for this: https://github.com/terser/terser/tree/27c0a3b47b429c605e2243df86044fc00815060f#mangle-options

Edit: Ah no, I'm wrong. Vite uses esbuild to minify now. https://esbuild.github.io/api/#minify-considerations

---

@romgrk maybe we should hide the eval call to code analyzer tools? using something like window[atob('ZXZhbA==')]("true") (this trick works in my minimal reproduction).

esbuild docs encourage to use https://esbuild.github.io/content-types/#direct-eval:

// Indirect eval (has no effect on the surrounding code)
let result = (0, eval)(something)

would this work? It would isolate the expression from the global scope.

[romgrk]

It's a bit different, eval does magic to preserve the lexical context in which it is called. Any indirect call doesn't:

I think we can work around that by adding another real closure around and passing arguments instead of closure values.

Let's move the discussion to #10056.