[Question] XSS risk in replay when `UNSAFE_replayCanvas` enables `allow-scripts`

Description:

When UNSAFE_replayCanvas is enabled, rrweb-player adds the allow-scripts sandbox permission to the replay iframe. If the recorded page contains malicious DOM like the following (e.g., because the recorded page itself has an XSS vulnerability, or was maliciously injected), it gets replayed as-is:

<img src="x" onerror="try{parent.alert(' Replay XSS!')}catch(e){try{top.alert(' Replay XSS!')}catch(_){}}"/>

During replay, the onerror handler is executed by the browser, triggering the alert popup.

Steps to reproduce:

1. Enable UNSAFE_replayCanvas: true
2. Record a page containing the <img onerror="..."> snippet above (or manually inject this DOM into the snapshot data)
3. Replay the recording
4. Observe that the alert popup fires

Expected behavior: Replay should not execute inline scripts/event handlers from the recorded content, even with UNSAFE_replayCanvas enabled.

Actual behavior: The onerror attribute is executed as code inside the replay iframe, resulting in XSS against the page hosting the replay (not the originally recorded page).

Question:

I understand that allow-scripts is required for canvas replay to function, and I understand why this behavior occurs. However, since the recorded data is effectively untrusted input (the recorded page itself may contain XSS), I'd like to ask:

• Is there a recommended way to keep canvas replay working while filtering/stripping inline event handlers (on* attributes) from the replayed DOM?
• Has built-in sanitization of on* attributes / javascript: protocol values (at record time or replay time) been considered?
• Is there an alternative sandbox configuration that would allow canvas-related script execution while still blocking inline event handlers like onerror?

Thanks!