c# - How do ViewModels prevent malicious database changes? -

while looking @ this answer question why use viewmodels?, came across section:

"a view should not contain non-presentational logic" , "you should not trust view" (because view user-provided). providing model object (potentially still connected active databasecontext) view can make malicious changes database.

what refer to? if have userid , password in model , viewmodel, security come in? kind of check in controller? check?

how determine can trust data view? handled antiforgery token?

i believe answer referring over-post problem. when utilize entity class directly view, , particularly if save posted entity directly database, malicious user modify form post fields should not able modify.

for example, let's had form allows user edit widgets. let's have row-level permissions, such user can edit widgets belong them. so, joe, our fictitious malicious user, edits widget he's allowed edit id 123. but, decides wants mess jane's widget, adds field form named id , gives value of jane's widget id. when joe posts widget form, jane's widget updated instead.

a view model not solely solving problem, negate issue because, inherently, cannot directly save view model database. instead, must map view model's values onto entity, before saving entity database. result, explicitly control , not mapped, in same example above, joe changing id ends having no effect because you're not mapping onto entity.

in truth, real problem here in directly saving posted user directly database. still feed entity class view "model", not save posted instance. instead, create new instance of entity or pull instance database fresh, , map values posted instance on that. again, wouldn't map property id, again joe foiled. in other words, it's not view model solves problem, it's never trusting user enough directly save created via post solves issue.

microsoft gives alternative solution in form of bind attribute, allows include/exclude properties on entity class modelbinding process (ignoring posted values, in other words). so, example, potentially solve issue above decorating param on action [bind(exclude = "id")], discard posted value id. however, bind horrible number of reasons, , should not use it. use view model instead, or don't ever directly save entity instance created modelbinder.