SafeHtml & XSS

The first output of the lab shows what the unsafe sink does and what the safe one does with the same string. The string is <img src=x onerror=pwn()> & "q" 'a', where pwn() is a function of the lab’s host page that only sets the document title (an alert would block a headless browser):

The img element was created and its onerror handler ran once, from a detached element that was never added to the page. The escaped version produced a single text node that shows the characters. The title change is the proof of execution; the same code with alert(document.cookie) would have been a session theft.

Source: GWT Javadoc — Element, GWT 2.13.1 source — Element.java

appendHtmlConstant and fromSafeConstant have two conditions. The argument must be fully determined at compile time, so that nothing a user typed can end up in it, and it must end in "inner HTML" context: it may not stop inside a tag or an attribute. The Javadoc gives the standard counter-example:

The second condition is checked, but only where checking is cheap. In client code the check runs in development mode only, and it is skipped in the compiled JavaScript. On the JVM it runs when assertions are enabled, or when the system property com.google.gwt.safehtml.ForceCheckCompleteHtml is set, or after SafeHtmlHostedModeUtils.setForceCheckCompleteHtml(true). The same four calls on a JVM, without and with -ea, and with the property:

Run your unit tests with assertions enabled (Surefire does by default) and the mistake is found before production. The compiled application accepted the incomplete constant silently: the lab’s production-mode build printed accepted (production mode skips the check).

Source: GWT 2.13.1 source — SafeHtmlHostedModeUtils.java

The generator’s parser is lenient about HTML syntax, but it refuses templates in which a placeholder is in a position that cannot be escaped safely. Ten deliberately bad interfaces in a probe module produced these messages, each followed by Failed to resolve '...' via deferred binding:

Two things are worth remembering from the table. A template is a compile-time asset, so the errors appear when you build, not when a reader opens the page. And a String in a style attribute is the one case where the generator warns and continues; treat that warning as an error in your build output and pass SafeStyles.

Templates are also the engine under UiBinder (see UiBinder). The configuration property UiBinder.useSafeHtmlTemplates is true by default in 2.13.1 (the module file calls it deprecated, discourages disabling it and announces its removal), so the HTML that a ui.xml file produces is escaped the same way, and ui:text and ui:safehtml in a template choose between an escaped text value and a SafeHtml value (see UiBinder). The 2.3.0 release notes describe the integration as off by default, with a build warning that your users were left "more vulnerable to cross-site scripting attacks" and a known-issues list; tutorials from that period show the property being switched on by hand, and the default has changed since.

Source: GWT Javadoc — SafeHtmlTemplates, GWT 2.13.1 source — SafeHtmlTemplatesImplMethodCreator.java, GWT 2.13.1 source — UiBinder.gwt.xml

The cell widgets (see Cell widgets) render a row to a SafeHtmlBuilder, so they are built on the same types. TextCell and ClickableTextCell extend AbstractSafeHtmlCell<String> and render through SimpleSafeHtmlRenderer, which escapes; SafeHtmlCell takes a SafeHtml value and appends it unchanged. With the hostile string of the lab:

So a TextColumn is safe for any string, and a SafeHtmlCell column is safe exactly as far as the SafeHtml values you give it. A custom cell extends AbstractCell<C> and writes into the SafeHtmlBuilder that is passed to render; use sb.appendEscaped(...) or a SafeHtmlTemplates call there, never sb.appendHtmlConstant with data. The example of The Bookshelf worked example: reader reviews is such a cell. The SafeHtmlRenderer<T> interface (in com.google.gwt.text.shared) is the way to plug a different rendering into the standard cells; AbstractSafeHtmlRenderer<T> is the base class to extend.

Source: GWT Javadoc — HasSafeHtml, GWT Javadoc — AbstractSafeHtmlCell, GWT Developer Guide — Custom Cells

SimpleHtmlSanitizer (which implements HtmlSanitizer) is the sanitiser that ships with GWT. It is deliberately tiny. It accepts only attribute-free tags from a fixed set: b, em, i, strong, br, hr, h1 to h6, ul, ol and li, plus numeric entities and entity references, and it escapes everything else:

Source: GWT Javadoc — SimpleHtmlSanitizer

The span and the script were shown as text. The b element with an onclick attribute was not allowed, because the allowlist covers tags without attributes; its opening tag was escaped, but the matching </b> closing tag, which is on the list, was kept. That is the limit the Javadoc states: the sanitiser does not promise well-formed or balanced HTML. An unbalanced closing tag cannot execute script, but it can close an element of your own layout early, so render sanitised output inside an element of its own. sanitizeHtml(null) throws NullPointerException: html is null. A JVM run of <b>a</b><b onclick=x>b</b></i>'&bogus; gave <b>a</b><b onclick=x>b</b></i>'&bogus;.

There is no method to sanitise an existing SafeHtml. The class comment explains why: such a method could return values that are not stable, so that sanitize(s.asString()) differs from s.

SimpleHtmlSanitizer fits snippets such as search results with b tags around the match. It does not handle links, images or styles at all, and it does not understand HTML the way a browser does. For anything richer use a real sanitiser.

The standard Java answer is the OWASP Java HTML Sanitizer (com.googlecode.owasp-java-html-sanitizer:owasp-java-html-sanitizer, 20260924.2 on Maven Central on 2026-10-09). It builds a policy from an allowlist of elements, attributes and URL protocols, and it runs on the server, so it can be used by the servlet that stores the review. It is not GWT-compatible and cannot be called from client code.

The lab ran that policy on three inputs and on the prepackaged Sanitizers.FORMATTING.and(Sanitizers.LINKS):

The disallowed elements and the content of the script element were dropped, the javascript: link lost its href, event handler and style attributes were removed, the allowed link got rel="nofollow", and the unclosed b was closed. The output is well formed, which the simple sanitiser does not promise. Its project page describes the library as protecting against XSS in HTML authored by third parties, and the project README gives the same builder API.

Where to put the sanitiser:

Source: GWT Javadoc — SimpleHtmlSanitizer, GWT 2.13.1 source — SimpleHtmlSanitizer.java, OWASP Java HTML Sanitizer README

The lab module (compiled with the default linker, xsiframe) was loaded in headless Chrome from a host page with no inline script, under five policies, and the page tried the unsafe innerHTML sink of Where XSS comes from in a GWT application in each. pwn() is defined in an external file pwn.js; the nonce values are placeholders (NONCE_PLACEHOLDER).

The last row failed with this message in the browser console:

The cause is the structure of the xsiframe linker. The nocache.js bootstrap creates a hidden iframe (it was visible in the dumped DOM as <iframe id="lab" ...>) and the permutation script is loaded into it. The nonce of your host page is not on that script, so without 'self' or 'strict-dynamic' the browser refuses it. 'strict-dynamic' makes scripts loaded by a nonced script trusted, which is the shape of a GWT bootstrap.

Source: MDN — Content Security Policy, W3C — Content Security Policy Level 3

The measurements give a starting point for a GWT host page that has no inline script, loads the bootstrap from its own origin and talks only to its own server. The lab module started under exactly this policy, the unsafe innerHTML of Where XSS comes from in a GWT application ran no handler, and inline styles worked:

Each directive has a reason that comes from GWT. style-src 'unsafe-inline' is needed because StyleInjector and CssResource.ensureInjected() write inline style elements, because markup with style attributes (such as the template output above) is subject to style-src, and because the StyleInjector source has no nonce support. img-src data: is needed because ClientBundle inlines small images as data URLs (see ClientBundle and images). script-src 'self' works for the lab’s output style because the nocache script, the permutation files and the policy-compatible RPC format come from your own origin (see the note on output styles below). A host page that must contain an inline script, for example a dynamic host page with initial data, should use a nonce or a hash for that block, or the type="application/json" data-block pattern that the deployment page shows (Server integration and deployment). The output style decides whether this holds. The default obfuscated output makes the xsiframe linker install each permutation as inline script text (script.text), so script-src 'self' alone stops such a module with an inline-script message, and the GWT-RPC lab saw exactly that. The module of this lab was compiled with -style PRETTY, for which the code is loaded from the permutation file, and it started under script-src 'self'; the direct_install and sso linkers start under that policy as well. With the obfuscated default, add 'unsafe-inline' or use a nonce together with 'strict-dynamic'. The Linkers and bootstrap page has the measured matrix of output styles, linkers and policies. In this lab the same message ("Executing inline script violates the following Content Security Policy directive 'script-src 'self''…​") appeared only when the code called ScriptInjector.fromString, so look for inline script in the host page or in code that injects text scripts when you see it.

If your host page has to use a nonce, give it to both the bootstrap tag and the data tag, add 'strict-dynamic', and generate a new unpredictable nonce for every response on the server:

Source: MDN — Content Security Policy

The nonce here is a placeholder: it must come from a secure random generator and change on every response, and never be a constant in a file.

ScriptInjector is the class for loading JavaScript at runtime (fromUrl and fromString). Its source, in nativePropagateScriptNonceIfPossible, looks for the first script element with a nonce attribute in the document and copies that nonce to the script element it injects. This is why fromString worked under the nonce policy and failed under script-src 'self' in the table above. It also means that the injected script gets the nonce of whatever the first nonced script is, so keep untrusted markup out of the document head. The behaviour is in the source and in the lab; the Javadoc does not describe it, and there is no nonce support in StyleInjector.

The module com.google.gwt.user.User defines a binding property gwt.cspCompatModeEnabled (values true and false, default false). The comment in UI.gwt.xml says it makes the widgets try to be compatible with strict CSP policies, for example by preventing the javascript:; default href of an Anchor from triggering an inline-script violation when the anchor is clicked, and that it "should be safe to enable and should have no user-visible effects". Set it in your module XML:

Source: GWT 2.13.1 source — UI.gwt.xml

CellTree already prevents the strict-CSP violation of its javascript: link target in 2.13.1 and cancels the default action of its links, as the comments in the source say. For your own code: do not use javascript: URLs, and call preventDefault() in the click handler of an Anchor that acts as a button. The JUnit support in JUnit.gwt.xml has a separate property, gwt.strictCspTestingEnabled, that makes GWTTestCase runs under JUnitShell add a Content-Security-Policy header (a nonce policy with strict-dynamic) to the module’s files so that a test fails when a widget violates it.

Source: GWT 2.13.1 source — ScriptInjector.java, GWT 2.13.1 source — UI.gwt.xml, GWT 2.13.1 source — JUnit.gwt.xml, GWT — Release notes

The server stores the review. The sanitising on the server uses the OWASP policy of Sanitising user HTML, and a servlet or a RemoteService method applies it before saving:

Four rules are in those few lines: check who is calling before anything else, bound the size, sanitise on write with a server-side allowlist, and keep only what you can show. Escaping the reviewer name on the server is not needed because the client escapes it on output; escape at the output, where the context is known. The client’s SimpleHtmlSanitizer and the rel="nofollow" remain as the second line of defence for reviews stored by older versions. The other server-side parts (token-based request-forgery protection, authorisation of every RPC method, safe file uploads) are on the XSRF, RPC and server security page.

Source: GWT Developer Guide — Custom Cells, OWASP Java HTML Sanitizer README