CSP: raise the policy to Level 3 strict

[norman-abramovitz]

With #5742 merged, the ZAP finding tracked in #5689 no longer reproduces and
the element half of #5705 is shipped. The scanner is quiet, but the policy is
not yet at the strongest level CSP offers. This issue collects what is left, so
the remaining steps are tracked somewhere their titles describe them.

Where the policy stands after #5742

default-src 'self';
script-src 'self';
style-src 'self' 'unsafe-inline' https://fonts.googleapis.com;
style-src-elem 'self' 'nonce-PLACEHOLDER' https://fonts.googleapis.com;
font-src 'self' data: https://fonts.gstatic.com;
img-src 'self' data:;
connect-src 'self';
worker-src 'self' blob:;
frame-ancestors 'self';
base-uri 'self';
form-action 'self'

Style elements are nonce-enforced, which is the CSP Level 3 mechanism for them.
Scripts are still governed by a host allowlist, which is CSP Level 1 thinking,
and several modern directives are absent.

A note on measurement

ZAP will not drive this work. Rule 10055 is satisfied and ZAP has no notion of
"how strict is this policy" beyond the specific patterns it looks for — it will
report a host-based script-src 'self' as perfectly fine. Anything below that
depends on 'strict-dynamic' should be judged with a tool that grades policies,
such as Google's CSP Evaluator, and confirmed in a browser with a violation
listener the way #5742 was. Worth saying up front so nobody chases a green
scanner as evidence of having finished.

The steps, roughly in order of value per unit of risk

1. object-src 'none'. Not declared today, so it inherits default-src 'self', which still permits same-origin plugin content. Every strict-CSP
reference profile sets this to 'none'. One token, no runtime behaviour to
break.

2. Violation reporting. No report-to endpoint exists, so an operator who
turns CSP on and hits a problem discovers it only when a user notices something
unstyled. Even report-only telemetry would have shortened the #5705
investigation considerably. This also makes every later step in this list
safely deployable, which is why it should come early rather than last.

3. script-src 'nonce-…' 'strict-dynamic'. The main event, and the step
that actually moves the policy to Level 3 strict. Under strict-dynamic the
host allowlist is ignored and trust propagates from nonced scripts to the
scripts they load, which is what makes an injected <script src="/…"> useless
to an attacker even when it is same-origin.

The server-side plumbing already exists: cspHeaderWithNonce substitutes every
occurrence of the placeholder, not just the first, so adding the token to a
second directive needs no backend change. What does need work is
injectNonce, which stamps <style> and <app-root> today and would need to
stamp the two build-emitted <script type="module"> tags as well.

The open question is Angular's lazy chunks. They arrive by dynamic import()
from an already-nonced module, which should inherit trust under
'strict-dynamic', but that needs verifying in a browser across a
lazy-route navigation rather than reasoning about — the failure mode is a route
that silently fails to load. The built-UI rig from #5742 is the right
instrument; ng serve cannot test any of this because it never runs
Jetstream's document handler.

4. Trusted Types (require-trusted-types-for 'script'). The strongest
option available and the largest lift. Angular supports it, but Monaco and
xterm are both unknowns, and #5705 is a good reminder of how that tends to go.
Worth scoping only after step 3 lands.

5. style-src-attr. Listed for completeness and explicitly not planned
here. It cannot be fixed by policy — CSP has no nonce or hash for attribute
values computed at runtime, and Monaco's per-line positioning and xterm's
per-cell colours are exactly that. It needs upstream conversion to the CSSOM,
which CSP exempts. Tracked at microsoft/vscode#288813.

Adjacent: the residual scanner warnings

The post-#5742 baseline scan leaves eight warnings, none High or Medium.
They are unrelated to CSP and unchanged by it, but they are the same class of
work and are cheap to fold in:

• Strict-Transport-Security not set (Low, high confidence). Genuine, though
  in most deployments TLS terminates at a router in front of Jetstream, so the
  right layer needs deciding rather than assuming.
• Permissions-Policy not set (Low). Straightforward addition.
• Cross-Origin-Opener/Embedder/Resource-Policy not set (Low). COOP is the
  one with real value; COEP has knock-on effects on cross-origin resources and
  should not be added casually.

Two more are low-confidence pattern matches on the minified bundle and want a
human look before being treated as real: Dangerous JS Functions (one hit,
lowest confidence) and Timestamp Disclosure (five hits, lowest confidence —
ZAP flags any ten-digit number as a Unix timestamp, which in a minified bundle
is close to meaningless).

The remaining informational entries are cache observations, and one of them is
self-inflicted on purpose: Non-Storable Content on the console document is
a direct consequence of the Cache-Control: no-store the nonce mechanism
requires. It should stay exactly as it is, and is noted here so it does not get
"fixed" by someone reading the scan cold.

Scope

Steps 1 and 2 are small and independent. Step 3 is the substantial one and
should be its own PR with the same before/after browser evidence #5742 used.
Steps 4 and 5 are not proposed for now.

[nabramovitz]

#5744 has merged, which clears the header-shaped items and sharpens what is
left here.

Now sent on every response: Cross-Origin-Opener-Policy: same-origin,
Cross-Origin-Resource-Policy: same-origin, and a Permissions-Policy that
denies the browser features the console does not use. HSTS landed behind a new
CONSOLE_HSTS, off by default. COEP is deliberately still absent and is now
labelled as a decision in three places rather than reading as an oversight.

Baseline scan across the two merges: 9 warnings and 58 passes → 2 warnings
and 61 passes, 0 failures. The two remaining are cache informationals, left
un-suppressed on purpose because that is where a genuine cache mistake would
show up.

Next step is violation reporting, not strict-dynamic

Of the ladder in the issue body, report-to should go next, ahead of the
script-src work. It is listed above as step 2 but the ordering deserves an
argument, because the instinct is to reach for strict-dynamic first.

Every remaining step on this list changes what the browser refuses to load, and
the failure mode of getting one wrong is silent. That is not speculation
about this codebase — it is what #5705 was: styles that were blocked while the
elements still looked correct in the inspector, a dead editor theme with no
console error, and a .sheet that reads null. It took a purpose-built
browser rig with a securitypolicyviolation listener to see any of it, and
that rig only ever ran on a developer's machine.

Without reporting, an operator who enables CSP and hits a problem finds out
when a user mentions something looks wrong. With it, the policy tells us
directly, from real deployments, on the surfaces our seven-URL unauthenticated
scan never reaches.

It is also what makes the rest of this list safely deployable. strict-dynamic
in particular has an open question — whether Angular's lazy chunks inherit
trust through dynamic import() — whose failure mode is a route that silently
never loads. Shipping that with no reporting channel means discovering it from
a bug report rather than from telemetry.

Concretely: report-to with a Reporting-Endpoints header, and worth
considering Content-Security-Policy-Report-Only alongside the enforced policy
so a future tightening can be measured against real traffic before it is
enforced. The endpoint has to be operator-configurable — Stratos has nowhere to
send reports by default and should not invent one.

Remaining after that, unchanged: object-src 'none' (one token, no behaviour
to break), then script-src nonce plus strict-dynamic, with Trusted Types
and the upstream-blocked style-src-attr still not proposed.

[nabramovitz]

Recording where this issue's remaining frontier stands after testing the upstream fix candidate.

Status recap

Steps 1–4 of the ladder are shipped and on by default: #5750 (object-src 'none' + violation reporting), #5752/#5753 (script-src 'nonce-…' 'strict-dynamic', worker-src blob: removed), #5754 (require-trusted-types-for 'script'). Step 5 (style-src-attr) remains the only open item, and it is upstream-blocked by design: Monaco and xterm write per-element style="…" attributes that no policy mechanism can authorize.

microsoft/vscode#288813 tested against our rig

The open upstream PR converts Monaco's inline style attributes to per-element nonced <style> tags. We ported its diff onto the monaco-editor 0.52.2 ESM we ship, bundled it standalone, and measured it in the real console page under an enforced style-src 'self' 'nonce-…' + style-src-attr 'none' policy — three runs (patched+nonce, patched without nonce, unpatched control), violation listener plus rendering and timing checks.

run	style-src-attr violations	rendering	create	20-step scroll	DOM nodes
unpatched control	1234	destroyed	72ms	162ms	890
patched, no nonce	1072	destroyed	66ms	158ms	890
patched + nonce	7	correct	65ms	309ms	1493

The approach is viable (1234 → 7 with a correctly rendering editor), but four defects reproduced live — invalid selector breaking line-number layout, decorations losing their caller-supplied class, copy-with-highlighting destroyed by clipboard sanitization of the (unnecessarily converted) clipboard HTML, and two missed emitters so zero violations is unreachable as written — plus a real cost: ~1.9× scroll re-render, +68% DOM (41% of editor nodes become <style> tags). Full write-up posted on the PR: microsoft/vscode#288813 (comment)

Decision recorded

• Keep what's shipped. The createElement nonce shim is library-agnostic, upgrade-proof, and is what lets style-src-elem run nonce-enforced. No ongoing cost.
• Do not carry a patched Monaco. The port touches ~15 files of render internals that drift between Monaco versions, and even a corrected version of the approach ships a measurably slower editor. Fork-maintenance cost is permanent; the residual risk it would close (style-attribute injection, with script injection already dead under strict-dynamic + Trusted Types) is second-order and already constrained by img-src/connect-src 'self'.
• style-src-attr stays as documented: upstream-blocked. If #288813 or a successor lands in good shape, consuming it is a routine version bump plus one policy token — that is the cheap win to wait for. Our measurement results are now on the PR to help it get there.
• An editor replacement (CodeMirror 6 measured CSP-clean under style-src-attr 'none' with a public nonce API) is the only durable self-serve path, but that decision belongs to its own cost/benefit (bundle size, YAML-schema tooling parity for the three schema-editing surfaces) — CSP alone does not justify it.

Nothing from the test entered the tree; the port existed only as measurement scaffolding.