Lol. Yes, funny how people love to throw JavaScript/Node.js into the mix.

It's like "They're using JS; how could it possibly be secure?!". That's actually highly ironic considering that JS is so far the only language that is secure enough to run universally in every browser on the planet.

People can't get around the fact that JS has evolved a LOT since it was launched and it still suffers a bad name.

You misunderstand why people think JS is insecure. The problem is that JS is really easy to make mistakes in because of silent errors, dynamic typing, type coercion, etc.

The result is that your server-side JS is more prone to different kinds of security issues.

On the client side, in the browser, JS is sandboxed, so the language is almost irrelevant. If JS can't actually access the underlying system, no number of bugs make the code insecure.

> The problem is that JS is really easy to make mistakes in because of silent errors, dynamic typing, type coercion, etc.

All those are not a factor in this instance. It seems to me it's a result of calling exec() on unscrubbed user input, and this can be done in any language.

I agree. I was responding to a tangential comment, rather than the root post.

Where here has JS been given a bad name? I didn't get that vibe.

One of those JS devs who gets really defensive when people are talking about JS and not screaming about how awesome it is.

Most of my experience saying you mostly do javascript in a room full of other coders is that they'll all scream at you to use a "better" language (on HN too).

Languages aren't inherently secure or insecure. In any case, nobody was accusing Node.js of being insecure here.

JS is not "the only language that is secure enough to run universally in every browser on the planet." In fact, JS has had many, many security issues in browsers.

Rather, JS is the only language nearly every browser on the planet has implemented in the browser (hopefully sandboxed!)

>Languages aren't inherently secure or insecure.

This is just not true.

Explain?

A language's specification can forbid you from doing things that you probably didn't intend to do. Rust is an entire language intended to be safer by design (as opposed to C, which is the cause of a lot of secure issues). You can write less safe code in Rust, but you have to tell the compiler that you're doing it on purpose.

It's also much, much easier to introduce bugs in certain languages because of the way they handle errors, or because the syntax is confusing and ambiguous. Even permissive handling of boolean logic, like what you get in PHP/JavaScript ("0" == true, for example) can result in massive security holes.

As another example, Go's := makes it much harder to do things you aren't intending to do.

Though it sounds like you're agreeing with me, that is not at all what I was saying.

Yes, I was just adding to your comment. Just pointing out that there is a pattern of people blaming JS even though it's not related at all to the problem. The same vulnerability would have existed regardless of whether the code was written in Python, Go, C, Erlang, Haskell, PHP or Scala... This is a logic error - Not something that a compiler would pick up.

In Haskell or Scala you could quite easily structure the code such that concatenating strings from different sources like that would be a compile error.

This is a massive design flaw, not a logic error. While I applaud the use of API's for modular design and communication, this is the wrong place for it.