fix(frontend): sanitize rendered markdown to prevent stored XSS (CWE-79)

[sebastiondev]

Summary

The frontend renders LLM responses and citation snippets as markdown, then injects the resulting HTML into the DOM via dangerouslySetInnerHTML. The shared useMarkdownRenderer hook returned marked.parse(content) directly without sanitization. Modern marked (v15) does not strip raw HTML, event-handler attributes, or javascript: URLs by default, so any HTML embedded in markdown reaches the DOM verbatim.

This results in stored XSS (CWE-79) for any user who views chat answers or citations derived from attacker-influenced content.

• CWE: 79 — Improper Neutralization of Input During Web Page Generation
• Affected hook: frontend/src/hooks/useMarkdownRenderer.ts
• Affected sinks:
  • frontend/src/components/chat/MessageContent.tsx (line 32) — dangerouslySetInnerHTML
  • frontend/src/components/citations/CitationTextContent.tsx (line 33) — dangerouslySetInnerHTML

Data flow

1. Attacker uploads a document containing a markdown/HTML payload to the RAG corpus (a normal user-tier action in this blueprint), or induces the LLM to echo a payload from a poisoned source.
2. Another user asks a question; the backend returns the answer and/or citation snippets containing the payload.
3. MessageContent / CitationTextContent call renderMarkdown(content) and set the result via dangerouslySetInnerHTML.
4. Embedded <script>, <img onerror=...>, or [link](javascript:...) executes in the victim's browser, in the application origin — allowing session/state exfiltration or authenticated API calls on the victim's behalf.

Fix

Sanitize the HTML produced by marked with DOMPurify inside the useMarkdownRenderer hook before returning it. Applying the fix at the central hook covers both MessageContent and CitationTextContent with one change and keeps future consumers safe by default.

const rawHtml = marked.parse(content, mergedOptions) as string;
return DOMPurify.sanitize(rawHtml);

Added dompurify and @types/dompurify to frontend/package.json. DOMPurify is the de-facto standard sanitizer for this scenario, is actively maintained by Cure53, and preserves benign markdown-rendered HTML (headings, lists, code blocks, links to http(s):, etc.) while neutralising script-execution vectors.

Tests

Added frontend/src/hooks/__tests__/useMarkdownRenderer.test.ts covering the three primary XSS vectors plus a regression check that benign formatting still works:

• <script> tags are stripped from rendered output.
• Inline event-handler attributes (e.g. onerror=) are removed.
• javascript: URLs in markdown links are neutralised.
• **bold** / _italic_ still render as <strong> / <em>.

Existing MessageContent and CitationTextContent tests mock the hook and continue to pass — no behavioural change for trusted markdown.

Security analysis

The fix mitigates exploitation by removing the dangerous HTML before it ever reaches dangerouslySetInnerHTML. Preconditions for the original issue are realistic in a RAG deployment:

• The attacker only needs the ability to influence corpus content — exactly the workflow this blueprint is built around (document ingestion).
• The victim is any other user of the same deployment who queries that content. Multi-tenant or shared-corpus deployments are the common case.

I checked for parallel render paths that might reintroduce the issue and didn't find any: both call sites go through useMarkdownRenderer, and there are no other usages of marked.parse in frontend/src.

Adversarial review

Before submitting, I tried to disprove this finding. I considered whether React's default escaping, a Content Security Policy, or marked's own options would already block the payload. React only escapes for normal JSX children — dangerouslySetInnerHTML deliberately opts out, which is exactly what's used here. I did not find a CSP header configured for the frontend that would block inline event handlers or javascript: URLs. marked v15's defaults render raw HTML as-is; there is no sanitize option in modern versions (it was removed in v8). I also considered whether the precondition (corpus upload) already grants equivalent access — it does not: uploading a document does not by itself give the attacker JS execution in another user's browser session, which is the new capability this XSS provides.

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's base branch to develop. The fix (4 files: useMarkdownRenderer.ts, its test, package.json, and package-lock.json) cherry-picks cleanly onto develop with no conflicts.

I'm hitting an OAuth scope limitation when force-pushing the rebased branch — GitHub's token doesn't have the workflow scope needed because the existing branch history includes workflow file changes from main. I'll sort this out and update the branch shortly.

[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.