security: XSS surfaces in statute rendering (JSON-LD </script> breakout + unsanitized markdown body)

[williamzujkowski]

Severity: HIGH — found during security review of apps/web

Statute content (frontmatter title/classification, markdown body) originates from OLRC XML→markdown. Treating it as untrusted (defense-in-depth; the build ingests external government data), two sinks render it unsafely.

H1 — JSON-LD </script> breakout (CONFIRMED mechanism)

apps/web/src/pages/statute/[...slug].astro:147

<script type="application/ld+json" set:html={JSON.stringify({ name: classification, headline: entry.data.title.replace(...), ... })} />

JSON.stringify does not escape <, >, /. A statute title/classification containing </script><img src=x onerror=alert(1)> terminates the script element; the remainder parses as live HTML. set:html adds no escaping.
Fix: escape after stringify — JSON.stringify(obj).replace(/</g, '\\u003c') (standard safe-JSON-in-<script> pattern; still valid JSON-LD).

H2 — statute markdown body rendered unsanitized (NEEDS-VERIFICATION on transformer)

apps/web/src/pages/statute/[...slug].astro:309 and apps/web/src/pages/browse/[title]/[chapter].astro:169 render <Content /> with no rehype-sanitize and no sanitize-html on the body. Astro passes embedded raw HTML through by default. If the XML→markdown transformer ever emits/relays raw HTML (<img onerror>, <iframe>, event handlers), it renders live. The repo already uses sanitize-html for GitHub data and search excerpts but not for the primary statute body.
Fix: add rehype-sanitize to the markdown config, or sanitize transformer output, or assert HTML-free transformer output (verify which guarantee holds).

M1 — CSP script-src 'unsafe-inline' negates its own anti-XSS value

apps/web/src/layouts/BaseLayout.astro:56 — the CSP is commented as "defense-in-depth against XSS" but 'unsafe-inline' permits inline onerror=/onclick= and inline <script>, so it does not stop H1's injected handler. The site uses many is:inline scripts, so tightening requires nonces/hashes. Either fix H1/H2 at the source (don't rely on CSP) or migrate to hashed/nonce'd scripts so 'unsafe-inline' can be dropped.

Clean (reviewed, no action)

Octokit/token handling (no token reaches client, GitHub data escaped/sanitized), RSS escaping (@astrojs/rss escapes standard fields), SearchBar {@html} (tight <mark>-only allowlist), getStaticPaths slug uniqueness, no eval/unsafe dynamic import.

[williamzujkowski]

H2 verdict (investigated): REAL stored-XSS surface, low likelihood — defense-in-depth fix warranted

Traced the data path end-to-end:

• Parser decodes entities (packages/transformer/src/parser.ts:30 processEntities), so <img onerror=...> in USLM text becomes the literal <img onerror=...>; CDATA passes through as literal markup.
• Text extraction does zero escaping — packages/transformer/src/xml-utils.ts:26-47 only collapses whitespace.
• The body is written into the .md unescaped (markdown-generator.ts:323); grep for escape/sanitiz in packages/transformer → no hits.
• The web renders it raw: apps/web/src/pages/statute/[...slug].astro:309 <Content />, and apps/web/astro.config.mjs has no rehype-sanitize / rehype-raw. Astro 6.x passes embedded HTML through. The existing sanitize-html only covers GitHub/search content, not the statute body.

Likelihood is low (USLM comes from OLRC, a trusted government source; no statute .md is committed; real USLM uses structural inline tags, not entity-encoded HTML — no live payload today). But there is no enforced guarantee; a malformed/compromised USLM doc or an OLRC encoding quirk could carry HTML into the body.

Recommended fix (defense-in-depth):

1. Render-side backstop — add rehype-sanitize to astro.config.mjs markdown.rehypePlugins (contained, low-risk; the transformer is meant to emit only markdown, so stripping raw HTML is safe).
2. Authoritative — escape </>/& in the transformer's extracted text so the .md is provably HTML-free at the source (note: escape only HTML-significant chars, not markdown syntax; transformer tests need updating).

Will implement (1) as the minimal fix; (2) can follow.

[williamzujkowski]

Status update + a newly-identified residual (from an adversarial review of the H2 fix)

Done & merged:

• H1 (JSON-LD </script> breakout) — fixed in fix(web): escape JSON-LD to prevent </script> breakout XSS (#200 H1) #203.
• H2 source-side — fix(transformer): escape < and > in extracted statute text (#200 H2) #207 escapes </> in extractTextFromNodes, neutralizing raw-HTML-tag injection in statute body text.

Residual identified during review of #207 — Markdown-syntax injection (new):
The source-side </> escape does not cover Markdown link/autolink/image syntax. Literal [x](javascript:…) (or <javascript:…> autolink, image syntax) in statute text would still compile to a live <a>/<img> via Astro's Markdown renderer. The transformer doesn't emit link syntax, so this only applies to such text passing through verbatim — very low likelihood, but it means "HTML-free via escaping" is not "injection-free."

Therefore the render-side control is required for completeness, not optional:

• M1 / render-side (now the authoritative remaining item): add rehype-sanitize to apps/web/astro.config.mjs markdown.rehypePlugins. This is the single control that closes both any residual raw HTML and the Markdown-injection vector (it sanitizes hrefs/protocols and strips disallowed elements after Markdown→HTML). It also lets the CSP be tightened off 'unsafe-inline' eventually.
  • Caveat (why this wasn't auto-shipped in the loop): it can't be verified locally — content-data/statutes is generated at import time and empty in the repo, so a build produces no statute pages to test against. It also needs care that heading anchors / ArticleToc and styling survive sanitization. Best done as a deliberate PR with a representative fixture page to verify both (payload stripped) and (normal rendering intact).

Suggested remaining scope for this issue: (1) add rehype-sanitize (closes the residual + raw-HTML backstop), (2) optionally the source-side Markdown-link escape if defense-in-depth at the data layer is wanted, (3) revisit CSP 'unsafe-inline' once inline scripts are nonce/hash-based.