-
Notifications
You must be signed in to change notification settings - Fork 364
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Unnecessary usage of eval requires unsafe-eval in CSP #1221
Comments
I'm currently having this problem trying to implement a library ( Thanks to your suggestion @arcticmatt, I monkey patched the library accordingly for my project - it works perfectly fine! |
We at Framer are also running into this and now thinking of maybe forking for this reason |
**Issue:** Sandpack currently uses `eval` to obtain the global object, which triggers CSP `unsafe-eval` violations. This poses security risks and limits the ability to use Sandpack in environments with strict CSP policies. **Solution:** Replaced the `eval`-based approach with an IIFE that sequentially checks for `globalThis`, `self`, `window`, and `global` to securely access the global object without violating CSP policies. **Testing:** - Tested in a local development environment with CSP enforced to ensure no violations occur. **Related Issue:** - [1221](#1221)
Bug report
Packages affected
Description of the problem
This code uses
eval("this")
. AFAICT this is unnecessary, and we could instead do something like:With the current approach, if you use
SandpackPreview
, it will raise an error unlessunsafe-eval
is included in your CSP. It would be better ifSandpackPreview
was usable without making the CSP less safe.@danilowoz I saw you introduced this code, curious for your thoughts here—I might be missing something about why
eval("this")
is used.The text was updated successfully, but these errors were encountered: