Riguardo a Domanda 1 :
In generale, si, lo è. Non conosci i dettagli di un potenziale attacco futuro, quindi il tuo compito è quello di rendere effettivo lo sfruttamento di qualsiasi vulnerabilità quanto più possibile.
Come sapete, la missione di sicurezza delle informazioni è fornire tre valori: riservatezza , integrità e disponibilità . Supponiamo che un hacker abbia ottenuto una copia completa del DB (che influisce sulla riservatezza ). Essendo in grado di accedere come utente, può assumere integrità (modificando i dati dell'utente e eseguendo azioni a suo nome) e disponibilità (ad es. Modificando l'e-mail che può essere usato per riottenere l'accesso.
Prima di passare alla domanda 2 . Per quanto ne so, MongoDB ha anche il controllo degli accessi a livello di raccolta, quindi potrebbe aiutare a limitare la propagazione degli attacchi. Puoi anche considerare di crittografare le voci sensibili in un DB in modo tale che l'accesso non autorizzato alla sola lettura non sarà così critico.
Riguardo alla domanda 2:
Non esiste un modo giusto perché le decisioni in materia di sicurezza devono essere prese sulla base di numerosi fattori che possono essere ricavati dall'analisi del rischio. È possibile memorizzare credenziali utente in un DB diverso o creare un server di autenticazione separato oppure utilizzare servizi di autenticazione di terze parti (OAuth).
L'obiettivo principale qui è mantenere un equilibrio tra il prezzo dell'attuazione, il supporto di quei controlli di sicurezza e una potenziale perdita che potresti avere in caso di violazione dei dati. La mia intuizione è di mantenerla semplice e seguire i consigli di sicurezza di base (come hashing delle password e segregazione degli accessi usando gli strumenti di controllo degli accessi MongoDB) combinati con altri controlli di sicurezza del sistema (come la rigida validazione dell'input dell'utente) che puoi trovare, ad esempio, in OWASP ASVS checklist .