fix(frontend): sanitize markdown HTML with DOMPurify to prevent stored XSS (CWE-79)

[sebastiondev]

Summary

Fixes a stored XSS vulnerability (CWE-79) in the frontend markdown renderer. Output from marked.parse() is passed through dangerouslySetInnerHTML without sanitization, allowing malicious HTML/JS embedded in retrieved RAG documents (or any other markdown source rendered through this hook) to execute in other users' browsers.

Vulnerability details

• CWE: CWE-79: Improper Neutralization of Input During Web Page Generation — Stored XSS
• Severity: High
• Affected hook: frontend/src/hooks/useMarkdownRenderer.ts
• Affected consumers: CitationTextContent.tsx and MessageContent.tsx, which render the hook's output via dangerouslySetInnerHTML.

Data flow

1. A document is ingested into the RAG corpus (typical deployment allows users to upload PDFs/text files).
2. During retrieval, citation text from that document is returned to the frontend.
3. useMarkdownRenderer calls marked.parse(content) — note that marked v5+ removed the built-in sanitizer option, so HTML embedded in the input is preserved as-is in the output.
4. The resulting HTML string is rendered into the DOM via dangerouslySetInnerHTML.

A document containing payloads such as <img src=x onerror=alert(document.cookie)>, raw <script> tags, or <iframe src="https://evil.example"> will execute in the browser of any user who views the citation or chat message containing it.

Fix

Wrap the markdown output with DOMPurify.sanitize() inside the hook, so both consumers (CitationTextContent and MessageContent) are covered by a single chokepoint:

const renderMarkdown = useMemo(() => (content: string) => {
  const rawHtml = marked.parse(content, mergedOptions) as string;
  return DOMPurify.sanitize(rawHtml);
}, [mergedOptions]);

dompurify (^3.3.3) and @types/dompurify are added to frontend/package.json. DOMPurify is the standard, well-audited library for this purpose and uses a strict allowlist by default, stripping <script>, event handler attributes (onerror, onload, …), javascript: URIs, <iframe>, and dangerous SVG/MathML constructs while preserving normal markdown-rendered HTML (bold, italics, links, lists, code blocks, etc.).

Tests

Added frontend/src/hooks/__tests__/useMarkdownRenderer.test.ts covering:

XSS prevention

• <script> tag stripping
• onerror handler stripping on <img>
• javascript: URI stripping on <a href>
• onload handler stripping on <svg>
• <iframe> stripping

Safe content preservation

• Bold (**...**), italic (*...*), links, lists all render correctly.

All tests pass under npx vitest.

Security analysis

We verified this is exploitable end-to-end:

• marked.parse() does not sanitize HTML by default since v5; the sanitizer option was removed in favor of delegating sanitization to the application.
• Both consumers use dangerouslySetInnerHTML, so the output is injected unescaped.
• Citation text originates from the retrieved document corpus, which is attacker-influenceable in any deployment that accepts user document uploads (the standard RAG Blueprint flow).
• No upstream sanitization or CSP was found that would block inline event handlers or injected script execution.

The fix sanitizes at the central hook so any future caller of useMarkdownRenderer is protected by default.

Adversarial review

Before submitting, we tried to disprove this finding. We checked whether the precondition (ability to ingest a document) already grants the attacker equivalent access — it does not: document ingestion is a corpus-level capability, while the XSS executes in another user's authenticated browser session and can exfiltrate session tokens or perform actions on their behalf. We also looked for an upstream sanitizer, a CSP that would block inline handlers, or a parallel safe rendering path — none exist. marked's own docs explicitly call out that consumers must sanitize the output themselves.

Diff scope

Minimal: the hook, its test file, and the package.json/package-lock.json entries for dompurify. No behavior changes for safe markdown content.

cc @lewiswigmore

[shubhadeepd]

Hi @sebastiondev thanks very much for your contribution! Please help rebase these changes on develop branch.

[sebastiondev]

Hi @shubhadeepd, thanks for the feedback! I've updated the PR base branch from main to develop. The fix commit itself only touches files under frontend/ (the 4 files for the DOMPurify XSS fix), so it should apply cleanly against develop. Let me know if you need anything else!

[lewiswigmore]

Closing this to reduce the open-PR pile-up — we have multiple outstanding security contributions to this repo and that volume is not fair on your review queue. Keeping #529 (CWE-89: escape document source values in delete filter (CWE-89)) as the primary one to focus attention on.

Happy to revisit this finding separately later if it is still relevant. Apologies for the noise.