js-framework-benchmark
js-framework-benchmark copied to clipboard
krausest
Note: Implementation doesn't pass strict CSP [sticky]
Update from @krausest: Please see this WIKI page for documentation of how the check is performed ** End of update**
Some frameworks, like mine, generate code at runtime, usually either via eval or via new Function.
In theory there could be no problems with that, but from the point of view of a user they must be more confident that something with no runtime code generation at all has no security issues deriving from that compared to something that uses runtime code generation.
There's also a CSP policy for preventing user code from generating code at runtime, as it's a desirable feature for many.
As such I think it would be useful to add an additional flag for marking frameworks that use this technique.
I was going to propose this flag myself, as people are "scared" by events delegation due flags, and not aware their library of choice might not even be usable in the wild due CSP constraints, so that having a library based on code evaluation / requires CSP workarounds flag would be way more interesting than benchmark specific implementations!
in short, I fully support this new flag and I'd be happy to help out flagging all libraries involved with a cumulative PR.
Good idea. I'll add the text to the result table soon and we'll use this issue as the target. Would be great if you added the issue in package.json where appropriate.
"js-framework-benchmark": {
...
"issues": [
1139
]
},
@krausest here we go: https://github.com/krausest/js-framework-benchmark/pull/1142 I've written some note there as the flag is actually all over the board but I've reasoned why I think that's actually the right choice, so that developers are aware that either the library or the tools used to ship the library in production can cause CSP issues, hence break the whole execution if CSP is not taken into account.
Not sure why Vue is flagged in in 018322f697e6906bb068b89ad68acd4610f2e47d - Vue 3 does not use runtime code generation when templates are pre-compiled at build time.
@yyx990803 this should've been amended after through automated tests, the initial PR simply looked for evaluation, it wasn't super accurate and few got removed (few others got added) later.
I switched to an automated check. See https://github.com/krausest/js-framework-benchmark/issues/1148 for details.
What if there is a variant/setting to disable runtime generated code? I think this would be sufficient to remove/change the notes. Or should I submit 2 benchmark entries? https://github.com/L3P3/lui?tab=readme-ov-file#noeval-variant
