O MongoDB evita o potencial de problemas por não analisar.

Qualquer API, em qualquer lugar, que envolva a codificação de dados do usuário em texto formatado que é analisado tem o potencial de o chamador e o receptor discordarem sobre como esse texto deve ser analisado. Esses desacordos podem ser problemas de segurança quando os dados são mal interpretados como metadados. Isso é verdade se você estiver falando sobre strings de formato printf, incluindo conteúdo gerado pelo usuário em HTML ou gerando SQL.

Como o MongoDB não analisa texto estruturado para descobrir o que fazer, não há possibilidade de interpretar erroneamente a entrada do usuário como instruções e, portanto, nenhuma possível falha de segurança.

Aliás, o conselho de evitar APIs que exigem análise é o item 5 em http://cr.yp.to/qmail/guarantee.html. Se você estiver interessado em escrever software seguro, vale a pena dar uma olhada nas outras 6 sugestões.

Atualização (2018):A resposta original que dei permanece fiel até onde sei. Do ponto do que é enviado para o MongoDB até o que é enviado de volta, não há ataque de injeção de SQL. Os ataques de injeção que conheço acontecem fora do MongoDB e, na verdade, são problemas em como linguagens e bibliotecas externas configuram a estrutura de dados que será passada para o MongoDB. Além disso, a localização da vulnerabilidade está em como os dados são analisados ​​no caminho para se tornar uma estrutura de dados. Portanto, a resposta original descreve com precisão como evitar ataques de injeção e o que o coloca em risco deles.

Mas essa precisão é um conforto frio para um programador que é atingido por ataques de injeção de defeitos que não eram óbvios em seu próprio código. Poucos de nós distinguem entre a ferramenta externa e todas as camadas entre nosso código e essa ferramenta externa. E o fato é que requer vigilância de nossa parte para antecipar e encerrar ataques de injeção. Com todas as ferramentas. E isso continuará a ser o caso para o futuro previsível.