Annotate fields or parameters with Jakarta Bean Validation constraints such as @NotNull and @Size, build a Validator, and call it on the object, or let your framework do it when a request arrives. Check the returned violations before using the data. Validation confirms shape, not safety.
What is Bean Validation?
Jakarta Bean Validation is a specification for declaring constraints on Java objects with annotations and checking them at runtime. The Jakarta EE site publishes the specification, and Hibernate Validator is its reference implementation. Constraints live on the data itself, so the same rules apply wherever the object is checked, whether in a web layer, a service or a persistence layer.
Built in constraints include @NotNull, @NotBlank, @Size, @Min, @Max, @Pattern, @Email, @Positive and @Past. You can also write your own.
How do you declare and run it?
Declare constraints on a class. A sign-up request might use @NotBlank and @Size(min = 3, max = 30) on a username, and @Email on an address. Use @Valid on a nested object field so its constraints are checked too.
Then run the check by hand with a factory:
ValidatorFactory factory = Validation.buildDefaultValidatorFactory();
Validator validator = factory.getValidator();
Set<ConstraintViolation<SignUp>> violations = validator.validate(signUp);
If the set is empty, the object passed. Otherwise each violation gives the property path, the invalid value and a message you can map to an error response. Build the factory once and reuse it, since creating it is expensive.
In frameworks such as Spring or Jakarta REST, you usually add @Valid to a controller method parameter, and the framework runs the validator and returns an error when constraints fail. You can also validate method parameters and return values directly.
Where should validation happen?
At the edge, before the data reaches business logic. Reject early and return a clear message. Keep a second check in the domain layer for rules that depend on stored state, such as uniqueness, which annotations cannot decide on their own.
Use groups when the same class has different rules in different situations, for example fewer required fields on update than on create. Use custom constraints for rules you repeat, like a valid product code.
What does validation not do?
This is the part that surprises people. Passing validation does not make data safe for every use. A string that satisfies @Size can still contain a SQL fragment or a script tag.
OWASP's Input Validation Cheat Sheet is clear that input validation is a first layer and not a replacement for output encoding and parameterised queries. Use prepared statements for databases, encode output for the context it lands in, and validate for syntax and business meaning on top of that.
Prefer allow lists over block lists. A pattern that describes what a valid value looks like is stronger than one that tries to list what is bad. And remember that regular expressions can be abused for denial of service if they backtrack badly, so keep patterns simple and bounded.
A constructed example
A payment endpoint takes an amount, a currency and a reference. Annotations require a positive amount, a three letter uppercase currency pattern and a reference of at most 40 characters. A test posts a negative amount and gets a 400 with a message naming the field. Good. But the reference is later inserted into a log line and into a report. The team encodes it for each output and uses a parameterised query for storage. Validation handled the shape, and the other defences handled the use.
How to check or apply this
- Add the Jakarta Validation API and Hibernate Validator to the project.
- Annotate request objects with constraints and mark nested objects with
@Valid. - Turn on validation in the framework for every public entry point.
- Map violations to clear, non sensitive error messages.
- Use allow list patterns and cap string lengths and collection sizes.
- Add tests that submit bad input and assert the rejection.
- Keep parameterised queries and output encoding in place regardless.
Quick check
Is Bean Validation the same as input sanitisation?
No. Validation accepts or rejects data against rules. Sanitisation changes data. Safe handling also needs output encoding and parameterised queries.
Do I need to create the Validator for every call?
No. Build the factory once and reuse it, because construction is expensive.
Sources
- Jakarta Bean Validation specification
- Jakarta Bean Validation 3.0 specification text
- Hibernate Validator reference guide
- OWASP Input Validation Cheat Sheet
Last reviewed: 18 October 2026.
