While obviously a step in the right direction, this approach is not always optimal, the reason being the developer must set this in each controller using @InitBinder. This duplicates effort and is error prone.
One alternative for the developer is to create Data Transfer Objects (DTOs). While this does indeed provide protection, as well as other architectural benefits, it is not practiced by many developers.
We have been considering such a mechanism before - either whitelisting bindable fields or blacklisting non-binding fields through an annotation as you suggest - but never got around to work out the details. I'll take your request as an opportunity to revisit this topic for 4.3...
Technically, we would implement such an auto-disallow for specifically annotated fields at the DataBinder level, which is also where the present "allowedFields" / "disallowedFields" mechanism resides. We can easily make the annotation type configurable and simply provide a convenience @NoBind (whatever the name) annotation that Spring MVC configures by default.
The lower-level BeanWrapper has a different mission and should remain capable of binding to any property.
Unfortunately, this turns out out to be non-trivial to implement at the DataBinder level, in particular with respect to the traversal of nested paths. We'll have to revisit the BeanWrapper versus DataBinder relatonship in a more comprehensive fashion, so I'm afraid this is rather a 5.0 topic in general... and we're very close to our 4.3 deadline already.