There is a huge "maybe" attached to that statement. It's also possible that several of the popular NoSQL databases could have key patterns that will corrupt memory in their C-code runtimes. There are good reasons to consider NoSQL databases, but security isn't one of them yet.

trying to understand what you just said: do you mean they may have buffer-overrun vulnerabilities, just as they are new projects? a lot of nosql projects are written in erlang and java btw.

I don't like the term "buffer overflow" because things haven't been that simple since the '90s (the recent Aurora kerfluffle happened because IE freed memory in the wrong order, no overrun involved). But yes, the point is you're trading a problem in a domain where we know how to mitigate problems for a maybe less likely problem in a domain where we have no idea how to mitigate problems.

Is there any reason why sql databases should be less vulnerable to that other type of problems?

Yes: because they've been tested extensively for over a decade for them, especially over the attack vectors exposed on web applications.

I'm pretty sure couchdb has a query language which can receive injections. If you pass JavaScript into mongodb theoretically you could open an injection problem if you don't use parametrization. But unless your nosql database has a native API, it still probably is vulnerable to command injection in the same way SQL databases are. Nothing really special about nosql itself that prevents this.

Preferred and typical use of MongoDB is with no javascript in the queries. There really is a huge reduction of risk for this one particular attack.

you may be right that i've overgeneralized to the other products based on my experience with mongodb; all i know for sure is mongodb has some nice properties here.

Yes mongo language drivers do make it harder to open up injection problems, but php extension like mysqli also provide similar protection. However the SQL-oriented nature does make it more likely that someone merges uncleaned input into a command.

That's the same side benefit that every SQL database has built in too, right? Pretty much every relational database has supported parameterized queries for, like, ten years. They're uninjectable and actually less work than constructing strings.

It's amazing that people are still constructing SQL queries as strings in 2010.

Sometimes you also need to change the query itself, i.e. the tables that are joined, or the sort order.

Indeed. And you either do that in Stored Procedures using parameters that you've passed in (without manipulating them as strings), or you construct your parameterized query on the webserver with the joins and sorts that you need, and then pass it to the database along with the parameters it needs to stick in.

Like I said. It's a solved problem, and has been so for a dozen years now.