Joris Kuipers opened SPR-7747 and commented
Currently one has to implement an @InitBinder annotated method to configure which properties of a form backing object can be used for binding request parameters to. It's often important to do this to prevent attackers from being able to bind to fields that shouldn't be exposed as writable to the web tier, esp. when domain objects are used directly as form backing objects. However, the current way of doing this involves referring to the properties of these form backing objects using hardcoded Strings (using the setAllowedFields or setDisallowedFields methods) from your controller methods, which is very refactoring-unfriendly and seems like an oldfashioned, pre-Java 5 approach.
I'd like to see support for annotating your classes used as form backing objects to indicate which fields are bindable. Non-annotated classes would behave like they do now for backwards compatibility, but adding an annotation to one or more fields would automatically exclude the non-annotated fields from participating in the binding process. Although this wouldn't cover all cases (some applications may have different actions that bind to the same type but with different binding restrictions, so this needs to be overridable on a case-by-case basis), I think it would cover the bulk of the binding restriction needs that people have. The easier we make it for users to apply proper security constraints to their application the better: right now it's simply too much of a hassle for some people to bother with configuring the WebDataBinder for each controller. Obviously I haven't completely thought this through, so the actual functionality might certainly be improved upon, but I'm sure this illustrates the general idea of what I'd like the framework to support.
Affects: 3.0.5
Issue Links:
- #18012 Add @FormAttribute attributes to customize x-www-form-urlencoded
- #18408 Addressing Mass Assignment vulnerabilities with @NoBind annotation for domain objects
- #19763 Data binding with immutable objects (Kotlin / Lombok / @ConstructorProperties)
7 votes, 3 watchers
Comment From: spring-projects-issues
Keith Donald commented
What about simply not defining a setter for a non-editable field?
Comment From: spring-projects-issues
Joris Kuipers commented
That can easily cause issues if the class isn't just used for web form binding: plenty of other libraries and frameworks need setters to do their work, for example certain ORM and OXM mappers. A field isn't non-updateble in general in some cases, it simply shouldn't be allowed to be used for binding request parameters to. I agree that most applications should define dedicated form classes that don't contain setters for non-bindable things, but in practice many developers prefer to be able to use a single set of classes, instead of having to create dedicated form classes for everything that needs to be edited in an HTML form. Even our development tools like Roo and Grails make this the default. If this wasn't the case, you also wouldn't need the set(Dis)AllowedFields methods.
Comment From: rstoyanchev
Closing as superseded, just like #18408. See this https://github.com/spring-projects/spring-framework/issues/18408#issuecomment-1651189240 for more details.