Confluence 11 strict CSP and WebAssembly: am I reading this right?
Reading the CSP section of Preparing for Confluence 11.0, I want to check my understanding before I rework a plugin the wrong way.
The default script-src in Confluence 11.0.0-m116 with http.header.security.content.security.policy.strictness.enabled=true contains neither 'unsafe-eval' nor 'wasm-unsafe-eval'. Chrome and Firefox therefore reject WebAssembly.instantiate():
CompileError: WebAssembly.instantiate(): Compiling or instantiating WebAssembly
module violates ... 'unsafe-eval' is not an allowed source of script ...
I can load and serve my own .wasm file fine (HTTP 200, application/wasm). The failure is purely the CSP policy rejecting WASM compilation.
And unless I’m missing something, CspFragment can’t fix this from the plugin side: getCSPOrigins returns Set<URI>, so I can whitelist external origins but not keyword sources like 'wasm-unsafe-eval'. I checked the <csp> module descriptor, the plugin XSD, com.atlassian.security.csp.api.*, Confluence’s CSP packages, and <web-resource> attributes. Nothing grants keywords.
So my read is that under strict CSP, no Confluence 11 DC plugin can ship client-side WebAssembly. That rules out sql.js, pdfkit/fontkit (harfbuzz-WASM), pdfium, Mermaid, Graphviz WASM builds, image codecs, client-side ML, anything compiling WASM at runtime. Even though 'wasm-unsafe-eval' exists precisely to permit WASM without opening up string-eval. W3C CSP3 defines it as a narrower, sandboxed keyword (see the WebAssembly CSP proposal).
Is that actually the intent? Two questions:
-
Will 'wasm-unsafe-eval' be added to the default script-src before strict CSP flips default-on?
-
If not, is there any plugin-side mechanism I’ve missed to contribute keyword sources?
For context on my side: Balsamiq Wireframes for Confluence parses .bmpr (SQLite) files client-side via sql.js. We already moved from sql.js 0.4.0 asm.js (eval-based) to sql.js 1.x WebAssembly, which is exactly the direction the docs push. Everything else on the CSP checklist is done: inline scripts nonced, onclick handlers removed, no eval or new Function anywhere in our code. The WASM instantiation is the only thing left, and as far as I can tell there’s no code change on my side that fixes it.
Would appreciate a sanity check from anyone who’s been through this, especially if 'wasm-unsafe-eval' is already on the roadmap or there’s an API I overlooked.