spring-framework/framework-docs/modules/ROOT/partials/web/web-data-binding-model-design.adoc

xref:core/validation/beans-beans.adoc#beans-binding[Data binding] for web requests involves
binding request parameters to a model object. By default, request parameters can be bound
to any public property of the model object, which means malicious clients can provide
extra values for properties that exist in the model object graph, but are not expected to
be set. This is why model object design requires careful consideration.

TIP: The model object, and its nested object graph is also sometimes referred to as a
_command object_, _form-backing object_, or _POJO_ (Plain Old Java Object).

A good practice is to use a _dedicated model object_ rather than exposing your domain
model such as JPA or Hibernate entities for web data binding. For example, on a form to
change an email address, create a `ChangeEmailForm` model object that declares only
the properties required for the input:

[source,java,indent=0,subs="verbatim,quotes"]
----
	public class ChangeEmailForm {

		private String oldEmailAddress;
		private String newEmailAddress;

		public void setOldEmailAddress(String oldEmailAddress) {
			this.oldEmailAddress = oldEmailAddress;
		}

		public String getOldEmailAddress() {
			return this.oldEmailAddress;
		}

		public void setNewEmailAddress(String newEmailAddress) {
			this.newEmailAddress = newEmailAddress;
		}

		public String getNewEmailAddress() {
			return this.newEmailAddress;
		}

	}
----

If a dedicated model object is not feasible, we strongy recommend registering
`allowedFields` patterns (case sensitive) on `WebDataBinder` in order to prevent other
properties from being set. For example:

[source,java,indent=0,subs="verbatim,quotes"]
----
	@Controller
	public class ChangeEmailController {

		@InitBinder
		void initBinder(WebDataBinder binder) {
			binder.setAllowedFields("oldEmailAddress", "newEmailAddress");
		}

		// @RequestMapping methods, etc.

	}
----

You can also register `disallowedFields`  patterns (case insensitive). However,
"allowed" configuration is preferred over "disallowed" as it is more explicit and less
prone to mistakes.