Security implications of client-side transient objects in Mendix 7

1
I was reading this section on transient objects in Mendix 7: https://docs.mendix.com/refguide/transient-objects-garbage-collecting. I was wondering what the security implications of this changes are (i.e. storing transient objects client-side).   For instance we are hosting several user registration forms on our mendix instances. In these forms user input is validated on each page and contained in non-persistable objects. However, if these non-persistable objects are stored client side it should be technically possible for a client to change the data after it has been validated on a page and before the complete form is submitted (in Mendix via a REST coupling). Does this mean that I need to revalidate all data just before I am calling the REST service to ensure that it hasn't been tampered with? Likewise, in a situation with a more complex CRUD REST Service connected to Mendix, could a user technically hack the GUIDs of transient objects prior to a READ call to retrieve different data, implying that you should only ever connect REST services with complete authorization models (i.e. you need to know for every object in your database which user is allowed to see them). I'd love to get a bit more clarity on this.
asked
1 answers
1

Attributes for which a user has 'write' permission, can technically be changed at any time by a user client side. Even if there are not pages, the user could use the client API to achieve this.

Attributes for which a user has read permission can be read from the system at any time (you can simply fire an XPATH query from the client API)

If Attributes are read-only the user cannot change them, even if the values are transient and only stored in the client. Mendix will use a kind of signature to verify that the client did not manipulate the object state.

I once had a similar question w.r.t. NPE: https://forum.mendix.com/link/questions/82122

answered