Petition to remove JS Playground tutorial

@yisrael-wix @aleksander-denga @brett-haralson
I think it’s an outright dangerous idea to suggest that people use eval() who are novices or even experienced devs who do not know how to use it safely, and how dangerous it can be to use it.

At the very least, the tutorial needs a bright red security warning. Even without theoretical access to the DOM, I think it should be proven that eval cannot be evil in Wix before recommending people use it.

https://www.wix.com/corvid/example/javascript-playground

2 Likes

Can we agree and disagree to this as if it is just through a user input on the page, then it should theoretically be safe for the user to use (cross fingers here) and not be open to people trying to inject their own data into it.

Although nowadays, if it is just being used on the front end, then is it not just the same as the person using the browsers own console? If it was being run server side then I would definitely would think again and would never use it.

To be honest, I don’t think many novices would even think about using something like this on their own site, the more experienced devs and programmers etc then yes, however as you’ve correctly pointed out that even they will need to know exactly what they are doing with it.

However, I would agree with your comment and hope that Wix has fully tested it and it is eval and not evil when used in Wix, although if it is up on Wix Corvid examples and they are letting anybody use it, then I would gather that they have already done all the necessary testing already.

Plus, even if Wix have done all that and given the green light, that as that code is open to anybody, then yes it would be best to have at least a warning section telling the user about the pros and cons of using eval etc.

At least Wix cover their own backs if something bad was to happen…

I think the fact that it’s a user input here isn’t so relevant, although your remarks about frontend code are certainly true. What difference does it make if you do it from the browser or from the input if the eval is still sitting there to exploit?

And the worries would be:

  1. These examples are rarely used standalone on a page, and any number of other functions are also running on the same page, as well as services connected to that page. That’s one big reason why eval is so vulnerable, not unlike SQL injections which are rarely exploited in a direct way, it’s always some roundabout exploit.

  2. Many times only bits of these examples are used because they have some semblance to the project they’re working on and they just want some way to loosely connect puzzle pieces until it works. In most cases, that approach is just sloppy, but with eval it’s more likely dangerous.

You’re hard pressed to find any other instance where eval is mentioned today without some sort of warning, and I don’t think this should be the exception. I think it’s better for the safety of people who barely understand what the internet is if we just deprecate eval and http - not because it’s impossible to use them securely, but because if you actually know how to use it securely, you’ll have ruled out other options for a reason to begin with.