Pegjs: Add a non-Eval alternative for Content Security Policy compatibility
Refactoring: remove "eval" from library
- Bug Report: Content-Security-Policy
Prerequisites
- **Can you reproduce the issue?: YES
- **Did you search the repository issues?: YES
- **Did you check the forums?: no
- **Did you perform a web search (google, yahoo, etc)?: yes
Description
Steps to Reproduce
1.Server set header: Content-Security-Policy: default-src https:
- Load vendor.js to the client
- Trying to .parse() with pegjs:
Error(chrome dev tools): Refused to execute inline script because it violates the following Content Security Policy directive: "script-src 'self' 'unsafe-eval'". Either the 'unsafe-inline' keyword, a hash ('sha256-NALaJ5yL9XVYFNSX8jAdayjJGG7VDRjzVeu1AYf0Kx0='), or a nonce ('nonce-...') is required to enable inline execution.
Software
- PEG.js: ^0.10.0
- Node.js: 8.12
- NPM or Yarn: 6.41
- Browser: Chrome 77, Safari, Firefox
- OS: Mac OS, Ubuntu
vldmr1986
All 12 comments
This does not look like an issue with pegjs.
Are you loading your scripts from an unsecure source (http?)
YemSalat
on 26 Oct 2019
I can reproduce this on the http and https protocols. It's all about security policy. If the code uses the eval function, then it will not be executed, the browser will block its execution
I have a workaround for that, but it is not secure.
More details about security policy:
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy
vldmr1986
on 26 Oct 2019
Your link is for http headers. You are in control of whatever headers you send on your server.
YemSalat
on 27 Oct 2019
Yes, this header is related to security, but which application in 2020 will not think about security. It's quite a common practice to use this approach in a modern web application.
I googled a bit and noticed that popular libraries have already made this update.
So, I do not think that many applications will ignore security in the future, and select appropriate tools that will be consistent with this.
vldmr1986
on 27 Oct 2019
Pegjs is a parser generator, it is a bit of a separate breed of JS libs,
How would JS inside grammar work without evaling it?
YemSalat
on 27 Oct 2019
bd82
on 27 Oct 2019
I dont think that is a good solution for a parser generator. Performance is pretty important here after all.
YemSalat
on 29 Oct 2019
I'm missing context in this issue. Can anybody finger-point at piece of relevant code?
langpavel
on 23 Nov 2019
I think it's worth adding a non-eval alternative for Content Security Policy compatibility; will see into this at some point before 0.12 by adding another bundle (maybe named dist/peg.csp.js) via a new entry file to be consumed by Webpack only
futagoza
on 12 Dec 2019
Probably don't make it webpack only. This problem isn't webpack specific, and webpack is rapidly on the decline, in favor of rollup and parcel
StoneCypher
on 2 Feb 2020
Honestly, there's no particular reason to leave eval in place if any alternative is provided. It's not like it's somehow faster, as oddly suggested above. Quite the opposite
StoneCypher
on 2 Feb 2020
This should not be flagged not-a-bug. It is, in fact, a severe bug.
StoneCypher
on 2 Feb 2020
Related issues
gatsbyz
·
3Comments
futagoza
·
13Comments
futagoza
·
6Comments
mikeaustin
·
7Comments
StoneCypher
·
8Comments
Most helpful comment
I think it's worth adding a non-
evalalternative for Content Security Policy compatibility; will see into this at some point before 0.12 by adding another bundle (maybe nameddist/peg.csp.js) via a new entry file to be consumed by Webpack only