5 ms·
No it’s not.
by kordlessagain 7mo ago
No it’s not.
- SahAssar 7mo agoIt really is. There are very few proper use-cases for eval.
- nswango 7mo agoFor a long time the standard way of loading JSON was using eval.
- _flux 7mo agoAnd why do we not anymore make use of it, but instead implemented separate JSON loading functionality in JavaScript? Can you think of any reasons beyond performance?
- bulbar 7mo agoWhy did you opt in for such a comment while a straight forward response without belittling tone would have achieved the same?
- _flux 7mo agoI actually gave it some thought. I had written the actual reason first, but I realized that the person I was responding to must know this, yet keeps arguing in that eval is just fine. I would say they are arguing that in bad faith, so I wanted to enter a dialogue where they are either forced to agree, or more likely, not respond at all.
- bawolff 7mo agoI'd be surprised if there is a performance benefit of processing json with eval(). Browsers optimize the heck out of JSON.
- fhars 7mo agoYou are arguing against the opposite of what the comment you answered to said.
- bawolff 7mo agoAm i? "Can you think of any reasons beyond performance?" implies that the comment author thinks performance would be a valid reason.
- _flux 7mo agoQuoting my original message: > And why do we not anymore make use of it, but instead implemented separate JSON loading functionality in JavaScript? In other words: I'm asking for reasons why was native JSON JavaScript module created, if we already had eval. > Can you think of any reasons beyond performance? One of the reasons is that native JSON parser is faster than eval: give some other reason.
- bawolff 7mo agoNot that long, browsers implemented JSON.parse() back in 2009. JSON was only invented back in 2001 and took a while to become popular. It was a very short window more than a decade ago when eval made sense here. Eval for json also lead to other security issues like XSSI.
- creatonez 7mo agoProblem is, it took until around 2016 for IE6 to be fully dead, so people continued to justify these hacks for a long time. Horrifying times.
- creatonez 7mo agoFor IE7 support, yes... https://caniuse.com/mdn-javascript_builtins_json_parse https://caniuse.com/mdn-javascript_builtins_json_parse
- pavel_lishin 7mo agoWhen is an eval not at least a security "code smell"?
- simonreiff 7mo agoOWASP disagrees: See https://cheatsheetseries.owasp.org/cheatsheets/Nodejs_Security_Cheat_Sheet.html https://cheatsheetseries.owasp.org/cheatsheets/Nodejs_Securi..., listing `eval()` first in its small list of examples of "JavaScript functions that are dangerous and should only be used where necessary or unavoidable". I'm unaware of any such uses, myself. I can't think of any scenario where I couldn't get what I wanted by using some combination of `vm`, the `Function` constructor, and a safe wrapper around `JSON.parse()` to do anything I might have considered doing unsafely with `eval()`. Yes, `eval()` is a blatant red flag and definitely should be avoided.
- jacquesm 7mo agoWhile there are valid use cases for eval they are so rare that it should be disabled by default and strongly discouraged as a pattern. Only in very rare cases is eval the right choice and even then it will be fraught with risk.
- godelski 7mo agoThe parent didn't say "there's no legitimate uses of eval", they said "using eval should make people pay more attention." A red flag is a warning. An alert. Not a signal saying "this is 100% no doubt malicious code." Yes, it's a red flag. Yes, there's legitimate uses. Yes, you should always interrogate evals more closely. All these are true