I’m on validation of JSON-input for my RestControllers. Validation is currently done by reflection - any field is detected and a global rule is validated (max string length, no special chars, etc). This can be superseded by annotations (longer string length, safe html, etc).
I would like to switch to the Hibernate Validator, but miss the ability to have a default security contract which is enforced if requirements are not altered by explicit annotations. I think a validator, by default, should validate all fields.
I don’t understand what you want. If you don’t have constraints there’s nothing to validate.
I think a validator, by default, should validate all fields.
Validate what on all fields? Hibernate Validator validates the constraints you put on your fields.
If you don’t have constraints there’s nothing to validate.
That is my problem. I think there are two reasons to validate input data:
- offload from business logic, as you call it in the spec, “metadata” to ensure the business case is working. All (at least many) of the tests to ensure that data is there and presented in a way the business case expects them are addressed by Hibernate Validator.
- enforce security: None of the provided strings must be unchecked, to avoid attacks of whatever kind. And as all of them have to be validated, we should not need to rely on the fact that every developer forces these checks. The validations should be part of the “environment”. Probably more than 90% of supplied strings in an application are shorter than 20 chars and do not contain special chars. Why not have an internal check to validate this. And if there are fields which need special chars (file upload, html or whatever) then lets override this with Size/Pattern/SafeHtml constraints.
I have shortly considered to combine my own validation with the Hibernate validator - but this will introduce conflicts or duplicate checks. Might give more problems than security.