MongoDB se vyhýbá potenciálním problémům tím, že neanalyzuje.
Jakékoli API, kdekoli, které zahrnuje kódování uživatelských dat do formátovaného textu, který je analyzován, má potenciál pro to, aby se volající a volaný neshodli na tom, jak by měl být tento text analyzován. Tyto neshody mohou představovat bezpečnostní problémy, pokud jsou data nesprávně interpretována jako metadata. To platí, ať už mluvíte o řetězcích formátu printf, včetně obsahu generovaného uživatelem v HTML, nebo o generování SQL.
Vzhledem k tomu, že MongoDB neanalyzuje strukturovaný text, aby zjistil, co dělat, neexistuje žádná možnost nesprávné interpretace uživatelského vstupu jako pokynů, a tudíž žádná možná bezpečnostní díra.
Mimochodem, rada vyvarovat se rozhraní API, která vyžadují analýzu, je položka 5 v http://cr.yp.to/qmail/guarantee.html. Pokud vás zajímá psaní bezpečného softwaru, stojí za to se podívat i na dalších 6 návrhů.
Aktualizace (2018):Původní odpověď, jak jsem ji dal, zůstává podle mého nejlepšího vědomí pravdivá. Od toho, co se posílá do MongoDB, až po to, co se posílá zpět, neexistuje žádný útok SQL injection. Injekční útoky, o kterých vím, se dějí mimo MongoDB a jsou ve skutečnosti problémy v tom, jak externí jazyky a knihovny nastavují datovou strukturu, která bude předána MongoDB. Kromě toho umístění zranitelnosti spočívá v tom, jak jsou data analyzována na cestě k tomu, aby se stala datovou strukturou. Původní odpověď proto přesně popisuje jak se vyhnout injekčním útokům a co vás vystavuje riziku.
Ale tato přesnost je chladnou útěchou pro programátora, který je zasažen injekčními útoky z defektů, které nebyly zřejmé v jejich vlastním kódu. Málokdo z nás rozlišuje mezi externím nástrojem a všemi vrstvami mezi naším kódem a tímto externím nástrojem. A faktem zůstává, že to vyžaduje z naší strany ostražitost, abychom mohli předvídat a uzavírat injekční útoky. Se všemi nástroji. A v dohledné době to tak zůstane.