Of course. This is an excellent question. "XSS protect Java" isn't a single library but a collection of best practices and tools used within the Java ecosystem to prevent Cross-Site Scripting (XSS) attacks.

Here’s a comprehensive guide covering the concepts, key libraries, and practical examples.

The Golden Rule: Contextual Output Encoding

The single most important principle for preventing XSS is Output Encoding, not Input Filtering.

• Input Filtering/Sanitization: Trying to remove "bad" characters (like <, >, &) from user input is brittle. Attackers are constantly finding new ways to bypass filters. It's a "whitelist vs. blacklist" battle you will likely lose.
• Output Encoding: Instead of cleaning the input, you "escape" the data right before you place it into an HTML context. This ensures that the browser interprets the data as plain text, not as executable code.

Example:

• Malicious User Input: <script>alert('XSS')</script>
• Without Encoding: The browser sees this as a script tag and executes it. VULNERABLE.
• With HTML Encoding: The input becomes <script>alert('XSS')</script>. The browser now displays the text <script>alert('XSS')</script> literally and does not execute it. SECURE.

The type of encoding you use depends on where the data is being placed (the "context"). The main contexts are:

1. HTML Body: Escaping <, >, &, , and .
2. HTML Attribute: Escaping <, >, &, , and .
3. JavaScript: Escaping characters in a way that is safe for a JS string.
4. CSS: Escaping characters in a way that is safe for a CSS value.
5. URL: Using URL encoding (%20 for space, etc.).

The Java EE / Jakarta EE Standard: jakarta.servlet.jsp.JspWriter

If you are using JSP (JavaServer Pages), the framework provides built-in mechanisms for encoding.

a) JSTL (JSP Standard Tag Library) - The Recommended Way

The JSTL <c:out> tag is designed specifically for this purpose. It automatically performs HTML entity encoding.

Vulnerable JSP:

<%-- DANGEROUS: Directly prints user input --%>
<p>Welcome, ${user.name}!</p>

Secure JSP using JSTL:

<%@ taglib uri="http://java.sun.com/jsp/jstl/core" prefix="c" %>
<%-- SAFE: <c:out> automatically HTML-encodes the value --%>
<p>Welcome, <c:out value="${user.name}" />!</p>

The <c:out> tag will take user.name and automatically convert < to <, > to >, etc., making it safe.

b) The JspWriter Escape Methods

You can also use the JspWriter's print() method with an escape flag. This is more direct but can be less readable.

<%-- Escapes the data for HTML context --%>
<%= org.apache.commons.lang3.StringEscapeUtils.escapeHtml4(user.getName()) %>
<%-- Or using JSTL's fn:escapeXml function (does the same as <c:out>) --%>
${fn:escapeXml(user.name)}

Note: While StringEscapeUtils from Apache Commons Lang is a great utility, <c:out> is the preferred method in JSPs because it's more declarative and harder to misuse.

Modern Java Web Frameworks: Spring Boot, etc.

In modern frameworks like Spring Boot, you typically don't write JSPs. You use templating engines like Thymeleaf or return JSON data to a Single-Page Application (SPA).

a) Thymeleaf

Thymeleaf is designed with security in mind. It automatically performs HTML escaping by default on any variable expression ().

Vulnerable HTML:

<p>Welcome, <span name="user-name">${user.name}</span></p>

Secure Thymeleaf (The Standard Way):

<!-- Thymeleaf automatically escapes ${user.name} -->
<p>Welcome, <span th:text="${user.name}">Default Name</span></p>

Thymeleaf will see th:text and automatically escape the content. To prevent this (only if you are 100% sure the content is safe and you want to include HTML fragments), you must use the th:utext (unescaped text) tag with caution.

<!-- DANGEROUS: Only use if you trust the source completely -->
<div th:utext="${user.trustedBio}"></div>

b) Returning JSON to a Frontend (SPA)

This is a very common architecture. Your Java backend is a REST API that serves data as JSON. The frontend (React, Vue, Angular) is responsible for rendering the data.

The key here is that your Java code does NOT render the HTML. The XSS protection is now the responsibility of the frontend framework.

• Your Java Code (e.g., with Spring): You just return the data. No encoding is needed on the Java side because you're not outputting HTML.

  @RestController
  @RequestMapping("/api/users")
  public class UserController {
      @GetMapping("/{id}")
      public User getUser(@PathVariable Long id) {
          // This is a POJO, not rendered yet
          User user = userService.findById(id);
          return user;
      }
  }

• Frontend Responsibility: The frontend framework has built-in protections. For example, in React, you use curly braces to insert data, and React automatically escapes it by default.

  // React component
  function UserProfile({ user }) {
    // React automatically escapes user.name and user.bio
    return (
      <div>
        <h1>{user.name}</h1>
        <p>{user.bio}</p>
      </div>
    );
  }

  If the frontend framework did not do this, it would be a critical vulnerability in the frontend, not the backend.

Standalone Java Applications / Desktop Apps

If you are building a Java application that needs to render HTML (e.g., an embedded browser like JavaFX's WebView), you need a library to perform the encoding manually.

The best and most widely used library for this is OWASP Java HTML Sanitizer.

OWASP Java HTML Sanitizer

This library is extremely powerful. It can do more than just simple encoding; it can parse a fragment of HTML and strip out everything that isn't on an "allowlist."

Add the dependency (Maven):

<dependency>
    <groupId>com.googlecode.owasp-java-html-sanitizer</groupId>
    <artifactId>owasp-java-html-sanitizer</artifactId>
    <version>20250608.1</version>
</dependency>

Basic Usage (Allowlisting only specific tags): This is the most common use case. You want to allow users to use bold and italic text, but block all scripts and other dangerous tags.

import org.owasp.html.HtmlPolicyBuilder;
import org.owasp.html.PolicyFactory;
import org.owasp.html.Sanitizers;
public class XssSanitizer {
    // Create a policy that allows only 'b' and 'i' tags
    private static final PolicyFactory POLICY = new HtmlPolicyBuilder()
            .allowElements("b", "i") // Allow only bold and italic tags
            .toFactory();
    public static String sanitize(String input) {
        if (input == null) {
            return null;
        }
        // Sanitize the input based on the policy
        return POLICY.sanitize(input);
    }
    public static void main(String[] args) {
        String maliciousInput = "<script>alert('XSS Attack!')</script> <b>Hello</b> <i>World</i>";
        String cleanOutput = sanitize(maliciousInput);
        System.out.println("Original: " + maliciousInput);
        // Original: <script>alert('XSS Attack!')</script> <b>Hello</b> <i>World</i>
        System.out.println("Sanitized: " + cleanOutput);
        // Sanitized:  Hello World
        // The script tag is removed, but the b and i tags are kept.
    }
}

Summary and Best Practices

Final Checklist for XSS Protection in Java:

1. NEVER trust user input.
2. ALWAYS use contextual output encoding at the point of rendering.
3. In JSPs: Prefer <c:out> over direct scriptlets.
4. In Thymeleaf: Use th:text by default.
5. In REST APIs: Focus on returning clean data and rely on the frontend framework's built-in protections.
6. For HTML Sanitization: Use the OWASP Java HTML Sanitizer library to define strict allowlists.
7. Implement Content Security Policy (CSP): This is a browser defense-in-depth mechanism that can prevent XSS attacks from executing even if they slip through. It's a critical layer of security.