Optional Jakarta Bean Validation integration backed by ESAPI Validator

[Sanjay44NS]

Idea: Optional Jakarta Bean Validation integration backed by ESAPI Validator

Context

In modern Java applications (Spring, Jakarta EE, Quarkus, Micronaut), Jakarta Bean Validation (JSR-380) is widely used for declarative input validation via annotations on DTOs and method parameters.

ESAPI provides strong, centralized input validation through org.owasp.esapi.Validator, but today it must be used imperatively, which often leads to:

• Repeated validation logic
• Validation scattered across controllers and services
• Teams choosing between Bean Validation or ESAPI, instead of using both

I wanted to start a discussion on whether it would make sense for ESAPI to offer an optional, official integration with Jakarta Bean Validation.

---

Idea (High-Level)

Provide a small, optional add-on module or package that exposes Bean Validation annotations backed internally by the existing ESAPI Validator.

Conceptually:

@ESAPIInput(type = "AlphaNumeric", maxLength = 50)
private String username;

Which internally delegates to:

ESAPI.validator().isValidInput(
    "BeanValidation",
    value,
    type,
    maxLength,
    false
);

This would allow developers to keep:

• ESAPI’s centralized security rules
• Standard Jakarta validation flows
• Fail-fast validation (no sanitization or mutation)

---

Design Principles (Open for Feedback)

• Purely additive — no changes to existing ESAPI APIs
• Optional — ESAPI core remains independent of Jakarta Validation
• Framework-agnostic — no Spring dependencies
• Validation only — output encoding remains explicit and separate
• Configuration-driven — respects existing ESAPI validation.properties

---

What This Is Not

• Not a replacement for ESAPI output encoding
• Not automatic input sanitization
• Not a framework-specific abstraction
• Not a breaking change

---

Questions for Maintainers / Community

1. Would this kind of integration align with ESAPI’s goals?
2. Would a separate module/package be preferred over core inclusion?
3. Are there concerns around encouraging annotation-based validation for security use cases?
4. Is there prior art or past discussion on this topic that I should review?

---

Willingness to Contribute

If this direction makes sense, I’m happy to:

• Prototype the module
• Add unit tests
• Write documentation
• Iterate based on feedback

At this stage, I’m mainly looking for architectural guidance before writing code.

---

Why This Could Help

Many teams already rely on Bean Validation for correctness checks and end up skipping ESAPI due to integration friction. A small, well-scoped bridge could help ESAPI adoption without compromising security principles.