Pegjs: Add a non-Eval alternative for Content Security Policy compatibility

Created on 24 Oct 2019  路  12Comments  路  Source: pegjs/pegjs

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:

  1. Load vendor.js to the client
  2. 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
discussion feature not-a-bug task

Most helpful comment

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

All 12 comments

This does not look like an issue with pegjs.
Are you loading your scripts from an unsecure source (http?)

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

Your link is for http headers. You are in control of whatever headers you send on your server.

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.

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?

I dont think that is a good solution for a parser generator. Performance is pretty important here after all.

I'm missing context in this issue. Can anybody finger-point at piece of relevant code?

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

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

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

This should not be flagged not-a-bug. It is, in fact, a severe bug.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

StoneCypher picture StoneCypher  路  8Comments

futagoza picture futagoza  路  6Comments

mattkanwisher picture mattkanwisher  路  5Comments

audinue picture audinue  路  13Comments

brettz9 picture brettz9  路  8Comments