org.owasp.esapi is the Maven group and artifact coordinate for OWASP ESAPI, the OWASP Enterprise Security API, a free Java library of security controls for encoding, validation, and access control. If you see org.owasp.esapi:esapi in a pom.xml or a dependency scan, you are looking at a project that pulls in ESAPI to handle tasks like output encoding and input validation. This guide covers what OWASP ESAPI provides, its maintenance status, the vulnerabilities that have affected it, and how to keep it from becoming a liability.
What org.owasp.esapi actually is
ESAPI predates most of the encoding utilities now built into modern frameworks. It was created to give Java developers a single, well-reviewed place to call functions such as ESAPI.encoder().encodeForHTML() instead of hand-rolling escape logic. The core pieces are:
- Output encoders for HTML, HTML attributes, JavaScript, CSS, and URLs.
- Input validators backed by allowlist regular expressions.
- Cryptographic helpers, an access-control reference implementation, and logging wrappers.
You add it with a single dependency:
<dependency>
<groupId>org.owasp.esapi</groupId>
<artifactId>esapi</artifactId>
<version>2.7.0.0</version>
</dependency>
The owasp esapi encoders are the part most teams still reach for, because context-aware output encoding is the primary defense against cross-site scripting (XSS).
Maintenance status: is ESAPI still alive?
ESAPI 2.x is in bug-fix and maintenance mode. New features are not being added, and ESAPI 3.0 remains in early planning. That said, the project is not abandoned: a small group of maintainers still ships releases, mostly to bump vulnerable dependencies. The org.owasp.esapi line continued to see releases through 2024 and 2025, including the 2.7.0.0 release.
Maintenance mode matters for a security library. It means you should treat ESAPI as stable-but-frozen: fine for the encoding functions it already does well, but not a place to expect new protections against newer attack classes. If you are starting a greenfield application, the built-in encoders in your framework (or the OWASP Java Encoder project) may be a lighter dependency.
Known CVEs in org.owasp.esapi
The most cited ESAPI vulnerability is CVE-2022-24891, a cross-site scripting flaw. The root cause was an incorrect regular expression for the onsiteURL rule in the bundled antisamy-esapi.xml configuration file. Because the regex was too permissive, URLs using the javascript: scheme were not always sanitized, which could let a stored XSS payload through ESAPI's cleaning step. It was fixed in ESAPI 2.3.0.0; versions up to 2.2.3.1 are affected.
If you cannot upgrade immediately, the maintainers documented a workaround: edit the onsiteURL pattern in your antisamy-esapi.xml file to the corrected expression from the release notes. Upgrading is still the right long-term move.
ESAPI has also shipped releases to resolve CVEs in its transitive dependencies. For example, version 2.5.4.0 upgraded the bundled AntiSamy to 1.7.5 to pull in the fix for CVE-2024-23635, and later releases addressed further dependency advisories. This is the recurring theme with ESAPI: many of its risks live in what it drags along, not in ESAPI's own code. A dependency scanner that resolves the full tree is the only reliable way to see them; an SCA tool such as Safeguard can flag a vulnerable ESAPI or a vulnerable transitive dependency of ESAPI before it ships.
Using ESAPI encoders correctly
The value of ESAPI is context-aware encoding. The single most common mistake is encoding for the wrong context. Data going into an HTML body needs different treatment than data going into a JavaScript string or an HTML attribute:
import org.owasp.esapi.ESAPI;
// Correct: HTML body context
String safeBody = ESAPI.encoder().encodeForHTML(userInput);
// Correct: HTML attribute context
String safeAttr = ESAPI.encoder().encodeForHTMLAttribute(userInput);
// Correct: inside a <script> string literal
String safeJs = ESAPI.encoder().encodeForJavaScript(userInput);
Encoding for HTML when the value lands inside a JavaScript block will not stop injection. Match the encoder to the sink.
For validation, ESAPI uses allowlist patterns defined in ESAPI.properties. Define what a valid value looks like and reject everything else, rather than trying to blocklist bad input:
boolean valid = ESAPI.validator()
.isValidInput("UserEmail", input, "Email", 254, false);
Configuration is a security surface
ESAPI reads two files at runtime: ESAPI.properties and antisamy-esapi.xml. Both are on the classpath, and both change security behavior. CVE-2022-24891 lived in the second file. Treat these files as security-relevant source: review changes to them, keep them in version control, and do not blindly copy a permissive antisamy-esapi.xml from an old tutorial. If you weaken the AntiSamy policy to let a stubborn input through, you may reopen the exact XSS hole the library exists to close.
When to keep ESAPI and when to move on
Keep ESAPI if you have a large existing Java codebase that already calls its encoders extensively; ripping it out has its own risk. Just pin a current version, scan the dependency tree, and monitor the org.owasp.esapi advisories.
Consider alternatives for new work. The OWASP Java Encoder is a focused, actively maintained encoding library with a much smaller footprint. Many web frameworks now auto-escape output in templates, which reduces how much manual encoding you write. If your only reason for pulling in ESAPI is encodeForHTML, a lighter option often fits better. Whichever way you go, pair the choice with dependency scanning and some XSS fundamentals from a resource like the Safeguard Academy.
FAQ
Is org.owasp.esapi still maintained in 2025?
Yes, but in maintenance mode. ESAPI 2.x receives bug fixes and dependency upgrades rather than new features, and releases continued through 2024 and 2025. ESAPI 3.0 is still in early planning.
What is the most important ESAPI CVE to know?
CVE-2022-24891, a cross-site scripting flaw caused by a faulty onsiteURL regex in antisamy-esapi.xml. It was fixed in ESAPI 2.3.0.0, and versions up to 2.2.3.1 are vulnerable.
Does owasp esapi protect against all XSS?
No. ESAPI gives you correct context-aware encoders, but they only help if you call the right encoder for each output sink. Misusing the encoders, or weakening the AntiSamy policy, can leave XSS open.
Should I use ESAPI or the OWASP Java Encoder for a new project?
For new projects that only need output encoding, the OWASP Java Encoder is lighter and actively maintained. Keep ESAPI where it is already deeply integrated, and pin a current version.