MongoDBは、解析しないことで問題の可能性を回避します。
解析されるフォーマットされたテキストでユーザーデータをエンコードすることを含むAPIは、どこにいても、呼び出し元と呼び出し先がそのテキストの解析方法について意見が一致しない可能性があります。これらの不一致は、データがメタデータとして誤って解釈された場合のセキュリティの問題になる可能性があります。これは、HTMLでユーザーが生成したコンテンツを含むprintf形式の文字列について話している場合でも、SQLを生成している場合でも当てはまります。
MongoDBは構造化テキストを解析して何をすべきかを判断しないため、ユーザー入力を命令として誤って解釈する可能性はなく、したがってセキュリティホールの可能性もありません。
ちなみに、解析が必要なAPIを回避するためのアドバイスは、http：//cr.yp.to/qmail/guarantee.htmlの項目5です。安全なソフトウェアの作成に興味がある場合は、他の6つの提案も検討する価値があります。
更新（2018）：私が与えた元の答えは、私の知る限り真実のままです。 MongoDBに送信されたものから返送されたものまで、SQLインジェクション攻撃はありません。私が知っているインジェクション攻撃はMongoDBの外部で発生し、実際には外部の言語とライブラリがMongoDBに渡されるデータ構造を設定する方法に問題があります。さらに、脆弱性の場所は、データ構造になる途中でデータがどのように解析されるかにあります。したがって、元の回答は、インジェクション攻撃を回避する方法と、インジェクション攻撃のリスクをもたらすものの両方を正確に説明しています。
しかし、この精度は、独自のコードでは明らかではなかった欠陥からのインジェクション攻撃に見舞われたプログラマーにとっては冷静な快適さです。外部ツールと、コードとその外部ツールの間のすべてのレイヤーを区別する人はほとんどいません。そして、インジェクション攻撃を予測して阻止するには、私たちの側で警戒が必要であるという事実が残っています。すべてのツールで。そして、これは当面の間当てはまります。