Strict CSP (nonce + strict-dynamic) with GWT – CSP violation from code-splitting

[Garima Jain]

Hi,

I’m working on a classic GWT application and trying to apply a strict Content Security Policy (CSP) using a nonce generated per request.

CSP Using:

default-src 'self'; script-src 'self' 'nonce-<dynamic>' 'strict-dynamic' 'unsafe-eval'; style-src 'self' 'unsafe-inline'; object-src 'self'; img-src 'self' data:;

What’s working:

• The app loads and runs correctly.

• GWT is able to load its scripts dynamically.

• The iframe now uses a safe URL (about:blank) instead of a javascript: URL and works with the current CSP.  

• No functional issues in the app.

What’s the problem:
Even though everything works, the browser console shows this error:

Running the JavaScript URL violates the Content Security Policy directive

The stack trace originates from GWT code-splitting (runAsync), specifically during execution of split fragments (e.g., application-0.js).
This appears to involve runtime JavaScript execution via javascript: URLs, which is blocked under strict CSP.

My questions:

1. Is there a supported way in GWT to avoid this javascript: execution when using code splitting?

2.   Is this console error considered a known limitation of classic GWT under strict CSP, and acceptable if the application works correctly?  

I’d like to keep CSP strict and avoid adding unsafe-inline.

Thanks!

[Garima Jain]

Hi everyone,

Following up to check if anyone has faced a similar issue with classic GWT and strict CSP.

The application works correctly with a nonce-based CSP and strict-dynamic, but a CSP console error still appears during GWT code splitting (runAsync), when split fragments (e.g., application-0.js) are executed via runtime javascript: URLs.

Error:

application-0.js:1835 Running the JavaScript URL violates the following Content Security Policy directive 'script-src 'self' 'nonce-kq/FBq3JY1ktQIm9FMZoYw==' 'strict-dynamic' 'unsafe-eval''. Either the 'unsafe-inline' keyword, a hash ('sha256-...'), or a nonce ('nonce-...') is required to enable inline execution. Note that hashes do not apply to event handlers, style attributes and javascript: navigations unless the 'unsafe-hashes' keyword is present. The action has been blocked.

If anyone has successfully resolved this CSP error (without relaxing CSP by adding unsafe-inline), I’d really appreciate it if you could share the approach or workaround you used.

Thanks in advance!

[Craig Mitchell]

I haven't faced this issue.  My GWT code splitting works fine, but maybe I haven't turned on all the content security policies.

You did ask this question before, and there was a suggestion to use a custom linker:  https://groups.google.com/g/google-web-toolkit/c/rzAAIIZxGUY/m/rDDPSDMQCAAJ

[Garima Jain]

Hi Craig, thanks for the response.

Yes, I tried the custom linker approach (GWT 2.12 + linker extending CrossSiteIframeLinker) earlier But my issue is not related to linker. GWT code splitting and script loading work correctly with nonce + strict-dynamic.

After further debugging, I realized the remaining CSP error is not coming from GWT’s linker or code splitting mechanism itself, but from Sencha GXT, specifically com.sencha.gxt.widget.core.client.form.FormPanel.

Using DOM inspection and a MutationObserver, I confirmed that FormPanel internally creates hidden iframes like:

<iframe src="javascript:''" ...>

This triggers the CSP console error under strict policies, even though the application functions correctly and all APIs return 200.

Now I want to confirm if there is any supported or tested way in GWT/GXT to:

• Prevent FormPanel from using iframe src="javascript:''", or

• Override/patch this behavior in a CSP-compliant way

Thanks

[Frank]

Isn't there a hash mentioned in the errorlog that you can add to the CSP?

Op maandag 2 februari 2026 om 12:39:49 UTC+1 schreef Garima Jain:

[Thomas Broyer]

Fwiw, GWT's own FormPanel has been using about:blank rather than javascript:'' for nearly 9 years specifically for Strict CSP compliance: https://github.com/gwtproject/gwt/commit/05091ff95a904b42246f5d9b90b6ae362c1bb5fb