Securing Form Fields with "ReadOnly" good enough?

I am new to Vaadin flow and have a security related question. I like to use Vaadin Flow to create some forms. Some of the fields of the same form or entity should not become editable if the user does not have the “Admin” role.

Vaadin supports for this to set the form field like TextField to “read-only” or to “disable” the field completely. I also have seen that the Binder supports the “Binder.forField(…).bindReadOnly(…)”

I am wondering which method I should use from a Security perspective because I noticed that in the Shadow root still a field gets rendered which potentially can be “hacked”.

So is Vaadin flow performing checks on the server side if a field is set to “read-only” but still gets transmitted by a malicious hacked client ? Or how has this scenario to be secured in Vaadin?

Securing Form Fields with “ReadOnly” good enough?

Sounds like a duplicate of https://stackoverflow.com/questions/76894260/vaadin-securing-form-fields-with-readonly-good-enough

The given answer is correct. I would add: don’t trust anyone - anything could have a bug or vulnerability somewhere, you should either make sure that your Backend does not accept such a changed value or have different methods like “save” which does not even touch the mail in any way and “saveAsAdmin” that does additional checks and is allowed to change the mail or some other way of making sure a tempered value isn’t stored. This is just another line of defense - theoretically speaking: Vaadin runs already on the server, so the genetic script kiddie attacks are not sufficient enough to temper with the server side state of Vaadin, especially since the field is read only and the binder does not call the corresponding setter.

Thank you, This would mean I need to use two different DTO classes for my entity, one which have the allowed setters and the other DTO which only has the getter for the protected fields? Would this be the pattern to address such requirement? Or any other smarter solutions?

“it depends” - if your Backend is within the same jar / service, I would go with a single DTO, if your Backend is on another system and you need e.g. REST to communicate your changes, I would go with different DTOs / what the Backend needs