No Content-Security-Policy: the app has no second line of defence behind the Markdown sanitiser

[usekaneo]

From the CON-43 security audit (2026-09-14). Severity medium, reachable in the shipped app.

index.html carries no <meta http-equiv="Content-Security-Policy">, and nothing in vite.config.ts, docker/ or scripts/ sets the header at serve time. A grep for Content-Security-Policy over the whole repository returns nothing.

Why it matters here

The audit found the Markdown pipeline itself clean — rehype-sanitize runs before the app's own rehype plugins, keepMentionUrls falls through to react-markdown's defaultUrlTransform for every scheme that is not a decodable nostr: mention, no dangerouslySetInnerHTML anywhere in src/, and Shiki is asked for tokens rather than HTML. So this is not a hole today.

It is the absence of a second layer. The entire XSS defence rests on that one pipeline staying correct, while the content it renders is written by arbitrary, mutually untrusted npubs, and the pipeline is built out of npm packages (react-markdown, rehype-sanitize, remark-gfm, shiki) that render that content. A CSP is what would still contain a future regression in our own sanitising, or a compromised release of one of those packages. That is exactly the case CSP exists for.

The detail that makes this less trivial than it looks

index.html contains an inline <script> — the theme bootstrap that must run before the bundle so light mode does not flash on every reload (docs/12-theming.md). A plain script-src 'self' breaks it. So the ticket has to pick one of:

• move the bootstrap into its own file and accept the extra request before first paint (it is tiny, but it is render-blocking by design),
• give it a hash ('sha256-…') and keep the hash in sync with the script — a footgun, because editing the script silently breaks the theme,
• or a nonce, which needs a server that can generate one per response and therefore rules out a purely static host.

Decide this deliberately; do not pick whichever makes the error go away.

Directives the policy needs

• script-src 'self' plus whatever the decision above requires. Not 'unsafe-inline'.
• object-src 'none', base-uri 'none', frame-ancestors 'none'.
• connect-src — the relay is a wss:// origin, and src/nostr/relay-status.ts:19 also does an https:// NIP-11 fetch against the same host. Note that the relay host is not fixed: it comes out of the space address in the URL (see the sibling ticket on parseGroupAddress), so a narrow connect-src and arbitrary relay hosts are in direct tension. Resolve that tension explicitly rather than widening the directive by reflex.
• img-src has to stay wide: loading images from arbitrary hosts is a deliberate decision (docs/09-security-privacy.md → "Images are loaded directly"). Say so in a comment next to the directive, so nobody later "fixes" it.

Acceptance

• A CSP is actually delivered — verified in the browser's network tab against a production build, not just present in a config file.
• The theme bootstrap still runs before first paint: no light flash on reload in dark mode.
• The app works end to end under the policy: page render, code highlighting, image loading, relay connect, Blossom upload.
• No 'unsafe-inline' and no 'unsafe-eval' in script-src.
• The chosen approach and its cost are written down in docs/09-security-privacy.md.
• npm run typecheck && npm run lint && npm test && npm run build pass.

Affected: index.html, vite.config.ts, docker/, docs/09-security-privacy.md, docs/12-theming.md

Source: CON-43, finding A1.

---

_{Task: wwr5yu38qczpy5f44w4dfmcx}

[usekaneo]

CON-44

[usekaneo]

**** commented:

Technical refinement — CSP

1. What the ticket assumes and what the repo actually has

• Verified again: a repo-wide grep for Content-Security-Policy returns nothing, and index.html has no CSP meta.
• docker/ holds only groups-relay.override.yml (the NIP-29 relay). There is no app Dockerfile, no nginx/Caddy config, no _headers/netlify.toml/vercel.json. package.json exposes dev, build and preview and nothing that serves dist/ under a policy. docs/07-tech-stack.md:5 describes the output as a static bundle "deployable to any static host"; NOSTR.md:15,33 state there is no deployment.
• Consequence: the ticket's Affected: docker/ has nothing to attach to yet, and acceptance item 1 — "a CSP is actually delivered … verified against a production build" — needs a serving step that the repository does not currently define. That step belongs to this ticket, not to a precondition.

2. Deliver it as a response header, not as a meta tag

A <meta http-equiv="Content-Security-Policy"> cannot deliver frame-ancestors, report-uri/report-to or sandbox: those directives are ignored when they arrive in a meta element and are only honoured as an HTTP response header. The ticket explicitly requires frame-ancestors 'none', so a meta-only policy cannot satisfy its own acceptance.

Recommendation:

• Put the production policy in vite.config.ts under preview.headers (and optionally server.headers for npm run dev). npm run build && npm run preview then serves the production build with the real header, which makes acceptance item 1 reproducible locally and in CI without inventing a deployment.
• Document the same header in docs/09-security-privacy.md as a host requirement (the static host has to send it; a meta tag is not a substitute). Where the host config itself lives is CON-4's business.
• Do not additionally put the policy in index.html as a meta tag: that creates two policies to keep in sync and breaks the dev server (next point).

The dev server must not get the production policy

@vitejs/plugin-react injects an inline <script type="module"> into index.html in dev (node_modules/@vitejs/plugin-react/dist/index.js:331-337, the Fast Refresh preamble), and Vite's HMR client opens a WebSocket to the dev server. A policy with script-src 'self' and no 'unsafe-inline' sitting in index.html therefore breaks npm run dev. Header-based delivery lets dev run with no CSP (or an explicitly permissive dev policy) while the shipped build stays strict.

3. Externalise the theme bootstrap

index.html:8-21 holds the inline bootstrap. Under script-src 'self' it is blocked, so it has to leave the document:

• Move the block verbatim to public/theme-bootstrap.js and load it with a classic, render-blocking tag: <script src="/theme-bootstrap.js"></script> in <head>, no type="module" and no defer. A module script is deferred, which reintroduces exactly the flash the bootstrap exists to prevent. Vite copies public/ verbatim, so no extra build entry is needed.
• Cost: one extra tiny request before first paint. That is the deliberate trade — it removes the inline block, the hash footgun and the nonce requirement (which a static host cannot serve anyway) in one move.
• Update the two places that describe the old mechanism: docs/12-theming.md ("No flash on load") and docs/10-roadmap.md:22 ("No flash on load | Inline script in index.html").

4. The directive set

Directive	Value	Why
default-src	'self'	fallback
script-src	'self'	no 'unsafe-inline', no 'unsafe-eval' (ticket requirement); bootstrap is external now, and src/ contains no eval/new Function (grep clean)
style-src	'self' 'unsafe-inline'	see below
img-src	* data:	deliberate — docs/09 "Images are loaded directly". Put a comment next to the directive saying so. * does not cover data:, so list it explicitly; no blob: is needed today (no createObjectURL in src/)
connect-src	'self' https: wss:	see below
font-src	'self'	no web fonts in the repo (no @font-face/fonts.googleapis hits)
object-src, frame-src, worker-src	'none'	no <object>, no iframes, Shiki runs its JS regex engine on the main thread (src/ui/code-highlight.ts)
base-uri, form-action, frame-ancestors	'none'	frame-ancestors needs the header form

style-src 'unsafe-inline' is forced by three React inline style attributes — src/ui/layout/TableOfContents.tsx:39, src/ui/layout/Sidebar.tsx:481 and :626. CSP governs style attributes through style-src as well (via style-src-attr), so without 'unsafe-inline' those three silently stop applying. The ticket forbids 'unsafe-inline' only in script-src, so this is allowed; write the reason as a comment in the config. If it is rejected, the three sites have to become classes or a non-attribute mechanism — that is a separate, mostly mechanical change and should be its own ticket rather than smuggled in here.

5. connect-src and arbitrary relay hosts

Everything the app opens a connection to:

1. the space relay from the route — ws:///wss:// plus the NIP-11 https:// fetch to the same host (src/nostr/relay-status.ts:13-19);
2. profile relays from VITE_PROFILE_RELAYS (src/nostr/relay-status.ts:75-78; in dev ws://localhost:10577);
3. the Blossom server from VITE_BLOSSOM_SERVER (src/nostr/blossom.ts:59);
4. the Vite HMR WebSocket in dev.

Because (1) is attacker-chosen at runtime (CON-46), no host allowlist can be built, so the only workable source list is scheme-scoped: connect-src 'self' https: wss: in the shipped policy, plus ws:/http: in the dev policy for the local relay and Blossom. State in a comment that this is the "we follow the link's relay" decision from CON-46 and not an oversight — otherwise the next reader "tightens" it and breaks every shared space link.

Interaction with CON-46: a known-hosts list there is a runtime value; a static CSP is fixed at build time. It therefore cannot become a narrow connect-src unless the deployment has exactly one relay host. That bullet in CON-46's scope should be corrected.

CON-45 narrows the host shape (rejects /, ?, #, @, whitespace), which is what keeps the derived origins well-formed. It is worth landing before or with this ticket.

6. Implementation order

1. public/theme-bootstrap.js + the index.html change; verify no flash in dark mode.
2. The policy value in one place (small exported constant or plugin in vite.config.ts), wired to preview.headers (and an optional dev policy).
3. Docs: docs/09 (policy + host requirement + the img-src comment), docs/12/docs/10 for the moved bootstrap.

7. Verification

• npm run build && npm run preview, then DevTools → Network → document response: the Content-Security-Policy header is present and script-src has no 'unsafe-inline'.
• Console is free of CSP violations during: page render, a code block (Shiki), an image from a foreign host, relay connect + NIP-42 AUTH, Blossom upload.
• Dark mode: hard reload, no light flash (CON-9's Playwright can pin this later; manual for now).
• The app still works with a non-local relay host, i.e. the scheme sources actually cover it.

8. Acceptance mapping

• item 1 (delivered, verified on a production build) — satisfied by the preview.headers path; the host still has to send it in production, which is documented.
• item 2 (no flash) — the external bootstrap; verify.
• item 3 (end to end under the policy) — the verification list above.
• item 4 (no unsafe-inline/unsafe-eval in script-src) — literal.
• item 5 (documented) — docs/09; item 6 — the four commands.

Risk to flag in review: the policy is only as good as the host that sends it. Until CON-4 picks a host and the header is configured there, the repo has a tested policy but production may not deliver it. Say that plainly in docs/09 instead of implying the app is already protected.

[usekaneo]

**** commented:

Implemented — branch con-44-content-security-policy (uncommitted, in its worktree)

Files: public/theme-bootstrap.js (new), index.html, vite.config.ts, docs/09-security-privacy.md, docs/12-theming.md, docs/10-roadmap.md.

Delivered exactly as the refinement directs: an HTTP response header via preview.headers, not a meta tag (a meta policy cannot carry frame-ancestors, which this policy requires). One definition, CSP_DIRECTIVES → CONTENT_SECURITY_POLICY in vite.config.ts, with per-directive reasoning as comments. The dev server deliberately gets no policy, with the reason written down: @vitejs/plugin-react injects an inline Fast Refresh preamble, so a dev policy would need 'unsafe-inline' in script-src — neutering the one directive this ticket is about.

default-src 'self'; script-src 'self'; style-src 'self' 'unsafe-inline'; img-src * data:; connect-src 'self' https: wss:; font-src 'self'; object-src 'none'; frame-src 'none'; worker-src 'none'; base-uri 'none'; form-action 'none'; frame-ancestors 'none'

The theme bootstrap moved verbatim to public/theme-bootstrap.js, loaded as a classic render-blocking <script src> — no type="module" (which is deferred and would reintroduce the flash), no hash, no nonce.

Verified independently, not taken from the agent's report

• curl -sI against vite preview on the production build returns the header above; script-src 'self' carries no 'unsafe-inline'. /theme-bootstrap.js serves 200 text/javascript.
• Built dist/index.html contains no inline script body at all — Vite emitted no modulepreload-polyfill block, so no hash is needed anywhere.
• npm run typecheck clean · npm run lint clean · npm test 44 files, 440 passed.

Two limitations, stated rather than hidden

1. A preview build cannot be clicked through against the local relay. connect-src 'self' https: wss: blocks ws://localhost:8080 and its http:// NIP-11 fetch. That is correct behaviour — production relays are wss: — but it means the three inline-style call sites (TableOfContents.tsx:39, Sidebar.tsx:481, :626) were not exercised live under the policy; reaching them needs a loaded space. They are covered by style-src 'unsafe-inline' per the style-src-attr rule, which is reasoning, not measurement.
2. The policy is only as good as the host that sends it. There is no app Dockerfile, no nginx/Caddy config, no _headers/netlify.toml/vercel.json in this repo, and no deployment. preview.headers proves the policy on the real artefact; production delivery is a host requirement, documented as such in docs/09 rather than implied to be done.

Minor, out of scope: eslint.config.js only covers **/*.{ts,tsx}, so the new public/theme-bootstrap.js is not linted. Not a regression — the inline script was not linted either.

[usekaneo]

**** commented:

Reviewed in worktree .claude/worktrees/agent-ac416a55b3ecafb2f (con-44-content-security-policy (uncommitted)). Verification run for this review on that worktree: npm run typecheck, npm run lint, npm test, npm run build — all four pass.

Review — CON-44: No Content-Security-Policy

Verdict

⚠️ Approve with nits. The diff is deliberate, correct and unusually well reasoned: it defines one policy, moves the theme bootstrap out of index.html so script-src 'self' can actually hold, and verifies the header on the production build through npm run preview. The one thing that deserves an explicit decision before CON-44 is closed is the delivery gap the docs themselves admit (docs/09-security-privacy.md:121-133): the policy is real and checkable, but no production serve path sends it. That is not a defect in this diff, but it is the ticket's headline outcome ("the app has no second line of defence"), so it should be wired or re-scoped, not only noted.

Summary

vite.config.ts gains a single policy definition (vite.config.ts:26-77) and attaches it as a real HTTP header via Vite's preview.headers (vite.config.ts:94-96), so npm run build && npm run preview serves the production artifact under the policy. To keep script-src 'self' free of 'unsafe-inline', the theme bootstrap leaves index.html for public/theme-bootstrap.js, still loaded as a classic render-blocking script (index.html:15). The non-obvious directives are resolved explicitly rather than reflexively: connect-src is scheme-scoped because the relay host comes from the URL, img-src stays * with the required comment, and the dev server deliberately has no policy. docs/09, docs/12 and docs/10 document the approach, its costs and — candidly — its limits.

Acceptance criteria

#	Criterion	Status	Evidence
1	A CSP is actually delivered, verified against a production build	⚠️ Partial	vite.config.ts:94-96 sets preview.headers; Vite 7 applies config.preview.headers to every preview response (verified against node_modules/vite/dist/node/chunks/preview.js:35208 and interface PreviewOptions extends CommonServerOptions {} in vite/dist/node/index.d.ts:667). The dist/ tree is a genuine production build (dist/index.html). But nothing outside vite preview sends it: docker/ contains only groups-relay.override.yml, and there is no nginx/Caddy/_headers/netlify.toml/vercel.json anywhere (docs/09-security-privacy.md:123-128 says so itself). Delivered on the preview harness; not delivered by any real host.
2	Theme bootstrap runs before first paint; no dark-mode flash	✅	index.html:15 is a classic, render-blocking <script src="/theme-bootstrap.js"> in <head> (no defer, no type="module"); public/theme-bootstrap.js:11-20 is the unchanged logic; dist/index.html:15 shows it survives the build immediately before the module entry (dist/index.html:16). docs/12-theming.md:124-143 explains the choice.
3	App works end to end under the policy	⚠️ Reasoned, not demonstrated	Clean by inspection: the Shiki WASM/unsafe-eval trap is avoided because the app uses the JS regex engine (src/ui/code-highlight.ts:2,82-88), and the built bundle contains no eval(/new Function; the single WebAssembly string is a language name in CodeMirror's language data, not a wasm compile. Images: vite.config.ts:48. Relay: wss: via connect-src, NIP-11 over https: (src/nostr/relay-status.ts:13-19,67). Forms call preventDefault, so form-action 'none' is safe (src/ui/layout/Topbar.tsx:109-113, src/ui/CreateSpaceForm.tsx:119-124). CodeMirror's runtime <style> needs style-src 'unsafe-inline' (present). However, the default .env.example:2 relay is ws://localhost:8080, which the policy blocks by design (docs/09-security-privacy.md:114-119), so a default preview cannot actually be exercised end to end; no run against a wss:// relay is recorded.
4	No 'unsafe-inline' / 'unsafe-eval' in script-src	✅	vite.config.ts:32 is exactly 'self'. No inline script remains: index.html:15,19 are the only <script> tags and both are external; dist/index.html has no inline script. src/ has no eval, new Function or Function(...) and no dangerouslySetInnerHTML.
5	Chosen approach and cost documented in docs/09	✅	docs/09-security-privacy.md:45-133 (policy, header-not-meta rationale, per-directive reasoning, dev-server decision, and the delivery risk); the policy string at :57-60 matches vite.config.ts exactly. Cost is stated (render-blocking extra request in docs/12-theming.md:141-143; no production delivery in docs/09:121-133).
6	npm run typecheck && npm run lint && npm test && npm run build pass	⏳ Not run here	Left to the separate CI job. The presence of a fresh dist/ indicates the build has run. .github/workflows/ci.yml:22-25 runs all four.

Findings

1. Major — the header is only ever sent by vite preview, so production still has no CSP

vite.config.ts:94-96

preview: {
  headers: { 'Content-Security-Policy': CONTENT_SECURITY_POLICY },
},

This is the entire delivery mechanism. vite preview is a local, dev-oriented static server; the repo has no app serving config at all — docker/ holds only groups-relay.override.yml, and there is no Dockerfile, _headers, netlify.toml, vercel.json, nginx or Caddy file. docs/09-security-privacy.md:130-133 states the consequence plainly: "the repo has a tested policy, and production does not necessarily deliver it … Do not read this section as 'the app has a CSP'."

Why it matters: the ticket's opening line is that "the app has no second line of defence", and after this change the shipped app still has none. Acceptance #3 ("The app works end to end under the policy") and the promise of a second layer only materialise once a host sends the header. The documentation is admirably honest, but candour is not delivery.

Suggested fix (pick one, make it concrete and tracked):

• Add at least one real serve-time mechanism in-repo, e.g. a public/_headers file (copied verbatim into dist/ by Vite, so Netlify/Cloudflare Pages deliver it), or an app Dockerfile + nginx add_header snippet. Prefer generating it from CONTENT_SECURITY_POLICY in a small postbuild script so there is still exactly one definition.
• Or formally change the acceptance to "policy defined and verified on the production build; header wiring is a deployment prerequisite", and open a follow-up ticket so the gap cannot quietly disappear with the PR.

If the acceptance criteria are read literally, this is the reason to hold CON-44 open even though the code itself is approvable.

2. Minor — the style-src 'unsafe-inline' rationale names the wrong/under-counted call sites and omits the binding constraint

vite.config.ts:34-40

// 'unsafe-inline' here is forced and deliberate: three components set a
// computed React `style` attribute (src/ui/layout/TableOfContents.tsx,
// src/ui/layout/Sidebar.tsx twice). …

There are actually five style={…} sites across three files, including the most numerous one the comment does not mention: Shiki token styles at src/ui/Markdown.tsx:180 (style={token.htmlStyle as CSSProperties}), plus src/ui/Markdown.tsx:131, src/ui/layout/TableOfContents.tsx:39, and src/ui/layout/Sidebar.tsx:481,626. More importantly, the load-bearing justification for style-src (as opposed to style-src-attr) is CodeMirror, not React: style-mod creates document.createElement("style") and assigns textContent (verified in node_modules/style-mod/dist/style-mod.cjs:93,128), and @codemirror/view constructs its StyleModule without a nonce (node_modules/@codemirror/view/dist/index.js:6789-6799). An inline <style> element is style-src-elem, and it is exactly what would be blocked without 'unsafe-inline'.

Why it matters: a future maintainer who trusts this comment could refactor the three named React sites (or decide CSSOM style assignment is exempt) and delete 'unsafe-inline', silently breaking the editor theme with no console error. docs/09-security-privacy.md:82-89 already mentions CodeMirror, so the config comment is also inconsistent with the doc next to it.

Suggested fix: correct the count/sites and add the CodeMirror <style> injection as the reason the directive cannot be removed without a nonce. Do the same one-line correction in docs/09-security-privacy.md:82-89.

3. Nit — the docs warn "do not tighten img-src by mistake", but nothing enforces any policy invariant

docs/09-security-privacy.md:90-94 warns explicitly not to narrow img-src, and vite.config.ts:29-32 warns that script-src must stay free of 'unsafe-inline'/'unsafe-eval'. Both are strong conventions with zero automated guard: CONTENT_SECURITY_POLICY is exported (vite.config.ts:75) but imported nowhere, and no test mentions CSP.

Suggested fix: add a tiny unit test (the export already makes this possible) asserting the invariants — script-src contains neither 'unsafe-inline' nor 'unsafe-eval'; object-src, base-uri, frame-ancestors are exactly 'none'; img-src still starts with *; and raw index.html contains no inline <script>. That last assertion would have failed against the pre-change tree, which is the point. If importing vite.config.ts in a test boots Vite plugins, extract the policy to a plain module (e.g. csp.ts) imported by both the config and the test.

4. Nit — acceptance #3 has no reproducible evidence, and the default preview env cannot exercise it

The policy intentionally excludes ws:/http: (vite.config.ts:57), while the documented default relay is ws://localhost:8080 (.env.example:2) — so npm run preview cannot connect to the relay or complete a Blossom upload on a default checkout. docs/09-security-privacy.md:114-119 explains this correctly. What is missing is the record that page render, highlighting, image loading, relay connect and Blossom upload were actually exercised under the header (against a wss:// relay) rather than inferred. Not a code defect; worth one line in the PR description or a VITE_RELAY_URL=wss://… preview note.

5. Nit — precise timing figures with no method recorded

docs/12-theming.md:141-143 states "the file was fetched 15 ms in and first paint happened at 84 ms". These are single, environment-specific numbers with no machine/build/method attached; they will read as a contract when someone later re-measures. Consider adding the environment (or softening to "well ahead of first paint on a local preview build").

Tests

No tests were added, and the change is mostly configuration, so this is defensible — but not empty. There is a real regression class here: a future edit that adds 'unsafe-inline' to make an error go away, tightens img-src, or reintroduces an inline <script> into index.html would pass CI untouched. Finding 3 gives a small, high-value guard. Beyond that, the existing suite is unaffected: nothing under src/ changed, npm test still exercises the Markdown sanitising path unchanged. The end-to-end claims in acceptance #3 are manual and, as noted, not demonstrated on a default checkout.

Docs

Docs are the strongest part of this change. docs/09-security-privacy.md:45-133 covers the policy verbatim, why it is a header and not a meta tag, each non-obvious directive, why dev has no policy, and — unusually and correctly — the risk that no host sends the header yet. docs/12-theming.md:124-143 documents the bootstrap move and its cost. docs/10-roadmap.md:22 updates the "No flash on load" row to point at public/theme-bootstrap.js. The docs/09 policy block (:57-60) matches vite.config.ts:26-77 exactly. Two accuracy nits only: the style-src justification (finding 2, repeated verbatim in docs/09:82-89) and the unsourced timings (finding 5).

What is good

• Choosing the external, classic, render-blocking bootstrap over a hash or nonce is the right call for a static host, and it is justified in place (index.html:8-15, docs/12:136-143) rather than chosen because it made an error go away.
• The scheme-scoped connect-src 'self' https: wss: (vite.config.ts:50-57) resolves the "arbitrary relay host vs. narrow policy" tension explicitly, with the reasoning and the CON-46 link written down.
• img-src * data: carries exactly the "do not tighten this" comment the ticket asked for (vite.config.ts:43-48).
• The Shiki/WASM trap is genuinely avoided: JS regex engine (src/ui/code-highlight.ts:2), no eval/new Function in src/ or the built assets, and worker-src 'none' is safe (no real Worker construction in the bundle).
• The honesty in docs/09-security-privacy.md:121-133 is better engineering communication than a claim that the app is now protected; it just needs to become a tracked deployment item.

[usekaneo]

**** commented:

Review response — CON-44 (worktree .claude/worktrees/agent-ac416a55b3ecafb2f, branch con-44-content-security-policy, uncommitted)

Four of the five findings are addressed; finding 1 is deliberately deferred, not done. Every claim the review makes was re-checked against the code before acting on it — one turned out to be right in a way the original comment was not, and the details are below.

Files touched in this round: src/csp.ts (new), src/csp.test.ts (new), vite.config.ts, docs/09-security-privacy.md, docs/12-theming.md. (index.html, public/theme-bootstrap.js and docs/10-roadmap.md are unchanged from the reviewed state.)

---

Finding 1 (Major — the header is only sent by vite preview) — deferred, tracked, not fixed

Confirmed as stated: preview.headers is the entire delivery mechanism, and there is no app Dockerfile, no nginx/Caddy config, no _headers/netlify.toml/vercel.json in the repo. The shipped app has no CSP.

No production host config was invented, on purpose: the project has not picked a host, and adding one would make that decision by accident. Instead the review's second option was taken — the gap is made unmissable rather than merely admitted. docs/09-security-privacy.md now opens the CSP section with a warning that the section describes a policy the app is meant to be served with, and the closing section is retitled "The risk: the app does not have a CSP yet", leading with "the shipped app has no Content-Security-Policy" and spelling out three consequences: the sanitiser is currently the only layer for real readers; the serve-time wiring is a deployment task left to whoever picks the host; and whatever that host is, the value must come from src/csp.ts rather than being retyped.

A follow-up ticket is needed for the actual serve-time wiring. Until it lands, CON-44 delivers a defined, guarded and build-verified policy — not a protected app.

On the review's suggested public/_headers: I considered it and judge against it. _headers is a Netlify/Cloudflare Pages format; it is inert on nginx, Caddy, S3+CloudFront or a plain container. Committing one picks a host family by implication and — worse — produces a file that looks like delivery while silently doing nothing on any other host. A documented, ticketed gap is more honest than a config that only works if an unmade decision happens to go one particular way. Generating it from CONTENT_SECURITY_POLICY would solve the duplication, not that problem.

Finding 2 (Minor — the style-src rationale names the wrong sites) — fixed; the review was right on both claims

Both specific claims were checked rather than taken on trust, and both hold:

• Count. grep -rn 'style={' src/ returns exactly five sites in three files: src/ui/Markdown.tsx:131 and :180 (the per-token Shiki styles), src/ui/layout/TableOfContents.tsx:39, src/ui/layout/Sidebar.tsx:481 and :626. The old comment said "three components … TableOfContents, Sidebar twice" — an undercount that omitted the most numerous site at runtime. The review is correct.
• CodeMirror / style-mod. Confirmed in the installed tree: node_modules/style-mod/dist/style-mod.cjs:87 takes the adoptedStyleSheets path only when !root.head — i.e. a ShadowRoot — and otherwise (:93, :128) does doc.createElement("style") plus textContent. This app mounts CodeMirror into a plain DOM parent (src/ui/MarkdownEditor.tsx:766, parent: host.current) and there is no attachShadow anywhere in src/, so the <style>-element path is what actually runs. @codemirror/view/dist/index.js:8308-8309 mounts it with a nonce only if the EditorView.cspNonce facet is set, which nothing here sets. So the review's central point is right: the binding constraint is style-src-elem from CodeMirror, which no refactor of our own React code can remove — only a per-response nonce could, and a static host cannot mint one.

The rationale is rewritten accordingly in both places: the code comment (now in src/csp.ts, see finding 3) leads with CodeMirror as the binding constraint and lists the five React style attributes as secondary and by itself removable; docs/09-security-privacy.md carries the matching correction.

Finding 3 (Nit — no automated guard) — fixed; this was the highest-value item, as the review said

Importing vite.config.ts from a test would drag in the Vite/React/Tailwind plugins, so the policy was extracted to a plain module: src/csp.ts exports CSP_DIRECTIVES and CONTENT_SECURITY_POLICY; vite.config.ts now imports CONTENT_SECURITY_POLICY from it and does nothing else with the policy. There is still exactly one definition. src/ (rather than a root csp.ts) because tsconfig.json includes src and every test in this repo sits next to its source — no config changes were needed. Nothing under src/ imports it, so it never reaches the bundle.

src/csp.test.ts asserts all five invariants the review asked for: script-src contains neither 'unsafe-inline' nor 'unsafe-eval'; object-src, base-uri and frame-ancestors are exactly 'none'; img-src still permits *; every directive is serialised into the header value; and raw index.html contains no inline <script> body (read through Vite's ?raw text import — there is no @types/node in this tree, so node:fs would not typecheck).

The "would have failed before" claim was tested, not asserted. git show HEAD:index.html > index.html, then npx vitest run src/csp.test.ts: 1 failed | 4 passed, the failure being the inline-script assertion reporting the old theme bootstrap body verbatim. index.html was restored immediately afterwards and git diff --stat index.html matches its pre-experiment state (8 insertions, 14 deletions).

Test count went from 44 files / 440 tests to 45 files / 445 tests.

Finding 4 (Nit — no reproducible evidence for acceptance #3) — addressed by recording the method; no measurement is claimed

docs/09-security-privacy.md gains a "How to exercise the policy by hand" section: why a default checkout cannot do it (.env.example points at ws://localhost:8080, which the policy blocks by design), the VITE_RELAY_URL=wss://<relay-host> npm run build && npm run preview recipe, the curl -sI header check, and the five console-clean paths that together are what acceptance #3 means (first paint/theme, a code block, a foreign-host image, relay connect + NIP-42 AUTH, a Blossom upload). It ends by saying plainly that this is the method and no such run is recorded for the current state of the branch.

What I did verify, and only this: after the extraction to src/csp.ts, npm run build followed by npm run preview still serves the header on the document, byte-identical to the documented policy —

Content-Security-Policy: default-src 'self'; script-src 'self'; style-src 'self' 'unsafe-inline'; img-src * data:; connect-src 'self' https: wss:; font-src 'self'; object-src 'none'; frame-src 'none'; worker-src 'none'; base-uri 'none'; form-action 'none'; frame-ancestors 'none'

and /theme-bootstrap.js serves 200 text/javascript. dist/index.html contains two <script> tags, both external, no inline body. That is header delivery on the real build — not an end-to-end run against a wss:// relay, which I did not do and do not claim.

Finding 5 (Nit — unsourced timing figures) — fixed by softening

The "15 ms in / first paint at 84 ms" figures in docs/12-theming.md are gone. I did not re-measure, so attaching an environment to numbers I did not produce was not an option. The passage now describes the shape of the trade — a few hundred bytes from the same origin, requested from <head> before the bundle, landing well ahead of the paint on a local preview build — and says explicitly that no figure there is a contract, naming a cold cache over a slow link as the case to re-measure if the flash ever returns.

---

Verification

Run from the worktree, in order, after the final edit:

Command	Result
npm run typecheck	pass, no output
npm run lint	pass, no output
npm test	45 test files, 445 tests, all passed
npm run build	pass, ✓ built in 13.78s (the pre-existing >500 kB chunk-size warning is unchanged)

Note for anyone re-running this: the worktree's node_modules was empty and needed npm ci first.

Nothing is staged and nothing is committed — the changes are left in the working tree for review, per the project rule.

[usekaneo]

**** commented:

UI test pass — 2026-09-15, PR #89, 1be37ac

Tested against npm run build && npx vite preview --port 4173, i.e. the real build with the real header. The policy itself is clean — the app produces no violations of its own. One finding needs a decision before merge.

What passes

• Header is delivered on the document, in header form, not <meta>:
  default-src 'self'; script-src 'self'; style-src 'self' 'unsafe-inline'; img-src * data:; connect-src 'self' https: wss:; font-src 'self'; object-src 'none'; frame-src 'none'; worker-src 'none'; base-uri 'none'; form-action 'none'; frame-ancestors 'none'
• npm run dev sends no header — confirmed, zero Content-Security-Policy response headers on :5273, exactly as the PR describes.
• Theme bootstrap works under script-src 'self'. /theme-bootstrap.js returns 200 and is included as a classic, render-blocking <script src> in <head> (index.html:15) — no defer, no async, so it runs before first paint. On load document.documentElement already carries data-theme="dark"; no inline script and no 'unsafe-inline' in script-src.
• The app violates nothing of its own. Isolation test: rebuilt with connect-src temporarily widened by ws://localhost:8081 http://localhost:8081 http://localhost:3355 and nothing else changed. Result on a fresh tab, space route loaded, relay connected: zero console messages at all — no CSP violation from React, CodeMirror's style-mod mount, Shiki's inline styles, or any asset. The style-src 'unsafe-inline' reasoning in src/csp.ts holds up: with it, nothing else is needed. (The widening was reverted and the build redone; src/csp.ts is unmodified.)

Finding: the policy forbids a plaintext relay, so the local setup cannot run under it

With the shipped policy, on /s/localhost:8081'engineering:

Connecting to 'ws://localhost:8081/' violates the following Content Security Policy
directive: "connect-src 'self' https: wss:". The action has been blocked.
Connecting to 'http://localhost:8081/' violates … The action has been blocked.
Fetch API cannot load http://localhost:8081/. Refused to connect …

Both the WebSocket and the NIP-11 fetch are blocked, and the relay stays permanently offline. 'self' does not help: the document is http://localhost:4173 and the relay is a different port, so it is not same-origin. VITE_BLOSSOM_SERVER=http://localhost:3355 falls to the same directive.

Three things follow:

1. This ticket's own acceptance criterion cannot currently be demonstrated. "The app works end to end under the policy: page render, code highlighting, image loading, relay connect, Blossom upload" — none of the content-dependent half is reachable, because the only relay available locally is plaintext and the policy blocks it.
2. It is compounded by the dev signer being DEV-only. src/dev/fake-nip07.ts (?devsigner) does not exist in a production bundle, so even with the relay reachable, a preview build cannot be signed in without a browser extension. Two independent reasons the signed-in surface cannot be exercised under the policy.
3. It contradicts CON-45's loopback carve-out. CON-45 deliberately keeps ws:// for localhost, 127.0.0.1 and [::1] — and this policy makes that connection impossible wherever the header is served. Both PRs are in the same wave.

For a production deployment this is probably harmless: real relays are wss:// and NIP-11 goes over https://. Nothing in the repo delivers the header in production yet anyway (CON-48). So the practical cost today is the loss of local verification, which is precisely what preview.headers was added for.

Worth deciding rather than discovering later. Options, cheapest first: state the limitation in docs/09-security-privacy.md and accept it; or let the preview-only policy add the loopback origins, so preview keeps verifying the real directives while the dev setup still runs; or widen connect-src by ws: (weakest — it permits plaintext to any host and undoes part of CON-45's intent).

Not covered

Code highlighting, image loading and Blossom upload under the policy — blocked by the finding above. Once a relay is reachable under the policy, these should be rechecked; the isolation run suggests they will pass, but it ran on a policy that is not the shipped one.