Regression: support for strict CSP broken by style mutation

The optimization in PR https://github.com/rrweb-io/rrweb/pull/464 broke support for users who run a strict Content-Security-Policy (CSP).

Specifically, this line sets the style attribute on a DOM node and will be blocked without style-src: 'unsafe-inline' (which is the unsafe CSP).

https://github.com/rrweb-io/rrweb/blob/661c746b14373dc3c360b2f6ce3e604e33887678/packages/rrweb/src/record/mutation.ts#L487

For any apps that pull in the affected versions and have a strict CSP, this issue will generate a very large numbers of errors like the one below (one for each time that line of code runs). As a possible side effect, any error reporting services or report-url endpoints may be quickly overwhelmed with error reports.

[razor-x]

@razor-x how does the document itself modify the style in the first place? (the original modification that generated the mutation) Could you have a look at the calling code for that and check how it’s actually doing it?

(via dev tools > inspector > (the element) > break on attribute modifications)

Sure. Just some more context on how I discovered the issue. I recently updated our app to MUI v5 which is supposed to have strict CSP compatibility now (since they switched to emotion / styled-components and no longer use CSS in JS). I enabled the strict CSP headers and tested the site in staging where we are NOT running rrweb and saw no errors. When moved to prod where recording is enabled, I saw the CSP errors triggered by the referenced mutation line from rrweb.

I actually would expect the app’s attribute updates to trigger CSP but there must be a reason they are allowed.

Here is one of the things triggering a modification that gets picked up by the rrweb mutation.

[eoghanmurray]

I’m agnostic; just not sure if #846 actually fixes it … presume it does. If possible, a general CSP test would be good to catch regression on this, or the emergence of new CSP violations.