research: zapproxy for another security checking code.

[norman-abramovitz]

https://www.zaproxy.org/

[nabramovitz]

Recording the current state of the ZAP work and the security-header findings it surfaced, so this issue tracks the remediation rather than just pointing at the tool.

Header findings and their status

OWASP ZAP (and earlier AppScan runs) flag a family of missing/weak response-header findings. Jetstream currently sets only X-Frame-Options: SAMEORIGIN. Status:

Finding	Status
Content-Security-Policy not set (Medium, CWE-693)	Header added in #5688 (opt-in via CONSOLE_CSP); moving to on-by-default. See CSP detail below.
CSP: Wildcard Directive	Resolved in #5688 (connect-src 'self', no ws:/wss: wildcard).
CSP: style-src 'unsafe-inline' (Medium)	Residual; tracked and re-scoped in #5689.
X-Content-Type-Options missing (#4926)	Not yet set. One line on the existing Echo Secure middleware (nosniff); no breakage risk.
Referrer-Policy missing	Not yet set. One line (strict-origin-when-cross-origin).
Strict-Transport-Security missing	Deployment-dependent (HTTPS/LB termination); should be configurable rather than forced.
Permissions-Policy missing	Cheap custom header (disable geolocation/camera/microphone/payment).
X-XSS-Protection	Deliberately not set — deprecated by browsers; current guidance is to omit it or send 0.

X-Content-Type-Options, Referrer-Policy, and Permissions-Policy are low/zero-risk additions that ride the middleware already in place and clear several findings at once.

CSP deep-dive result

A full audit of every inline-style source in the frontend (detail in #5689) changed the premise. The common belief that "Angular forces style-src 'unsafe-inline'" is not true for enforcement:

• CSP style-src-attr enforces only against the markup path — a literal style="…" attribute in HTML and Element.setAttribute('style', …).
• Angular's [style.*], [ngStyle], Renderer2.setStyle, the animation engine, and CDK Overlay all write via CSSOM (element.style.setProperty(...)), which CSP does not enforce against.

Across 60 style bindings + 6 animations + 3 CDK usages: 0 cascade-forcing, 0 CDK-coupled, and only 9 literal style="…" markup attributes are actually enforced — all static, all trivially converted to classes. The rest reflect a style="" into the DOM but are not browser-enforced.

So removing 'unsafe-inline' is small: convert the 9 literals to classes, and nonce the <style> elements (Angular's injected component styles + the index.html splash) via a per-response nonce.

Planned sequence

1. Land the CSP header (feat(security)(jetstream): optional opt-in Content-Security-Policy header (CONSOLE_CSP) #5688), then make it on-by-default with CONSOLE_CSP=off as the operator opt-out.
2. Add per-response nonce plumbing (nonce injected into the served index.html and the header; Angular reads it via ngCspNonce).
3. Convert the 9 literal markup styles to classes; verify each affected view is visually unchanged.
4. Drop 'unsafe-inline' from style-src and re-scan.

Open question this issue should answer

A static scanner greps the rendered DOM, where it still sees the reflected style="" attributes from the CSSOM bindings, CDK overlay, and two live animations. Whether ZAP flags those depends on whether it distinguishes a CSSOM-reflected attribute from a markup-parsed one. One scan after step 4 settles it. If ZAP is green, the work is done. If it still flags the reflected attributes, taking them out of the DOM entirely (SVG geometry for the charts, dropping one JS-only animation) is scanner-cosmetic — the CSSOM residual is not a control the browser was enforcing — and would be scoped separately.

[nabramovitz]

Status update. ZAP has now been used on Stratos in earnest rather than just
evaluated, so this records what that established and what is still open.

What has been done

It runs, and it found something real. ZAP 2.17.0 has been driven against a
Jetstream-served build two independent ways — the official zap-baseline.py
from ghcr.io/zaproxy/zaproxy:stable, and a passive plan through ZAP's
automation framework. Both reach the same results.

It produced one Medium finding, CSP: style-src unsafe-inline [10055], which
became #5689 and was fixed in #5742. ZAP then verified the fix: two Jetstream
instances with identical builds differing only in the policy string gave
WARN-NEW ×4 on the old policy and PASS on the new one, with all eight other
warnings identical in name and instance count. So it is usable both to find a
problem and to confirm a fix, which is the more valuable of the two.

Its CSP semantics are now understood from its own source, which mattered
because the naive reading sent us the wrong way initially. Rule 10055 is a pure
header parse. It never inspects style-src-attr, and it never looks at the
DOM. The practical consequence is that converting markup style="…" attributes
to classes moves that rule by exactly zero — worth doing as hardening if you
want, but never as scanner remediation.

A limit worth writing down: ZAP has no notion of how strict a policy is. It
scores a host-based script-src 'self' as perfectly fine, so it cannot drive
the remaining CSP work and should not be treated as the measure of it. That is
recorded in #5743, which uses CSP Evaluator plus a browser violation listener
instead.

Current baseline output on the post-#5742 build: 8 warnings, zero High,
zero Medium. Roughly triaged:

• Genuine but unrelated header gaps: HSTS (Low, high confidence),
  Permissions-Policy, and the Cross-Origin-Opener/Embedder/Resource policies.
  COOP is the one with real value; COEP has knock-on effects and should not be
  added casually.
• Two are low-confidence pattern matches on the minified bundle and want a
  human look before being treated as real: Dangerous JS Functions (one hit) and
  Timestamp Disclosure (five hits — ZAP flags any ten-digit number as a Unix
  timestamp, which in a bundle is close to meaningless).
• The rest are informational cache observations, and one is self-inflicted on
  purpose: Non-Storable Content on the console document is a direct
  consequence of the Cache-Control: no-store the CSP nonce requires. It
  should stay exactly as it is.

Reproducing it requires the built UI under Jetstream — ng serve serves
index.html itself and never runs Jetstream's document handler, so it cannot
exercise any response header. With a build served on 5543:

docker run --rm -v "$PWD":/zap/wrk/:rw ghcr.io/zaproxy/zaproxy:stable \
  zap-baseline.py -t https://host.docker.internal:5543 -J report.json -I

What is left

Authentication is the big one. Every scan so far has been unauthenticated,
and the spider reached exactly seven URLs — /, robots.txt,
sitemap.xml, favicon.ico and the three JS/CSS bundles. That is the login
page and static assets. None of the API surface, none of the authenticated
application, and none of the endpoint or CF proxy paths have ever been scanned.

This matters for how much weight the clean result carries: what has been
validated is ZAP's easiest mode against the smallest part of the attack
surface. The CSP header work happened to live exactly there, which is why it
felt conclusive. Getting past login needs a ZAP context with a session
management and authentication configuration.

Only passive rules have run. zap-baseline.py does not active-scan, so
nothing has been probed for injection or the other classes ZAP is actually best
at. Whether to run an active scan, and against what environment, is a separate
decision — it is not something to point at a shared foundation casually.

It is not wired into anything. make audit currently runs fifteen scanners
and ZAP is not among them, nor is it in CI. Every run so far has been by hand.
If it should join the make audit flow, two things need deciding: whether it
runs baseline or active, and whether its output can feed the existing
dist/*.sarif summary and upload path — ZAP's report templates need checking
for SARIF support.

Suggested order: authenticated context first, since it is what makes every
subsequent scan worth more; then a decision on baseline versus active; then
integration. Keeping this issue open to carry that rather than opening another.