Understanding the reasoning behind ROV (Read-only Views) for collections

Hi there! I am creating a relatively basic web application that contains sensitive user information in a users table along with other information that would be used in various views on the frontend. I came across this article that discusses the security advantages of creating ROV’s for data in the database. In the article, the author specifically refers to a case where a malicious user somehow gains access to the backend server of the application, and could then use custom queries to access data on the DB. What I don’t understand is that if a user has access to the server via SSH, they could just theoretically query the database for any collection (including non-ROV collections) because the IP address is accepted on the MongoDB side.

I also looked to see if there was some DB-side functionality where tables could be “write / modify only” but everything I found suggested abstracting those permissions to server-side code, which runs into the same problem as above.

If this is the case, I don’t really see the advantage of creating ROV’s as it doesn’t seem to solve the use-case it is designed to solve.

Clearly I am missing something here, and would love some clarification from someone more experienced :pray:

Hi @Jake_Myers ,

If the hacker only has access to the application server and the application uses a user that only allowed to query limited views they are only able to access those objects

The full collection is inaccessible for this user , therefore a hacker will somehow needs to get access to an admin user to do so.


Wouldn’t the application have to be able to update the actual documents on say account creation? At some point the sensitive collections need to be updated with information and there needs to be a server that uses a user with those permissions.