I think the issues are the same as they always have been. No matter what your platform, you can't trust user input. Your OS has to be as secure as it is reasonable to make it. Obscurity is not security. Security is an onion. Don't store unencrypted passwords. I could go on for days with apparently trite security aphorisms, but we ignore them at our peril. The issues that are raised in the articles linked in other comments here are not new.

People have been showing scary insecurity demonstrations for decades, and they will for decades more. In any given instance it may or may not mean a thing. People have been picking on one or another popular language or platform or database forever as well, and still companies manage to build successful products and businesses on those very tools.

If you are building something people might actually use, you do have a responsibility to weigh the security issues carefully. Don't let that stop you from building something that people will use, in a way and in a time frame that it is viable for to build it.

The security and access restrictions are pretty basic in nosql databases. Never run them on VPS / machines with a public IP, When using a nosql database you are left to rely on network and OS level security.

Basically keep your databases running on a internal firewalled network that accept connections only from certain trusted hosts.

2) Use a recent version of os with all known security patches applied , preferably something like a *nix server.

3) Never let the end user know what database you are using.

If I wanted to host on Heroku and use MongoHQ, do these sites tend to implement the security you're talking about?

I am not sure about these, as I am not from the Ruby side. That said I am considering to talk with fibervolt.com / linode.com , to see if they can get this done for me.

NoSQL databases are very new , and the application I am planning to use it (MongoDB) can easily run in multiple terabytes a month, as of today I haven't come across anyone who has used it at that scale. Just FYI..so if this something mission critical, do your due diligence on taking the nosql approach.. I chose it because I had no other choice, as I cannot have a preset schema.

Server-Side JavaScript Injection: Attacking NoSQL and Node.js https://securosis.com/blog/nosql-and-no-security

Yeah, the article says it is a threat which prompted me to ask here but they don't explain much more than that unfortunately. I was looking for a detailed explanation of how it works and what can be done to avoid it.

There are a few details (and a theoretical example) in this article: http://queue.acm.org/detail.cfm?id=1964843

Server-side javascript injection? There's no such thing. Node doesn't work like that. It doesn't accept and execute javascript over HTTP at all.

Same concerns as any web stack: CSFR, DB injection, leaving sensitive data/files exposed over the web, allowing remote DB connections, etc.