fix: restore dropped nginx headers and harden the runtime image

[oto-macenauer-absa]

What

Two deployment-layer issues, grouped because they are the same three files and the header fix needs a new file that the Dockerfile has to ship.

The header bug — #45

add_header in nginx does not merge across configuration levels. A block that declares any add_header discards every add_header inherited from its parent. Two location blocks each set a Cache-Control, and in doing so silently dropped the CORS and security set declared at server level:

• location ~* \.(css|js|woff2?|…)$ → every static asset
• location ^~ /knowledge-base/ → every page

Between them that is all real traffic; the server-level headers only ever applied to / and /healthz.

Verified against a real nginx container rather than argued from the docs — the pre-fix config, same probe:

path	before	after
/knowledge-base/	missing all 4	all present
/knowledge-base/style.css	missing all 4	all present
/__wf/knowledge-base/style.css	missing all 4	all present
/	all present	all present

Fix

The shared set moves to nginx.headers.conf, included by the server block and by every location that declares a header of its own. One place to add a header; the include is what makes it reach everything.

It lives outside conf.d/ deliberately — nginx loads conf.d/*.conf as top-level server configuration, and this is a fragment.

Also in this file

• X-XSS-Protection dropped, not restored. The legacy XSS auditor is gone from every current browser and the header has a history of introducing vulnerabilities rather than preventing them.
• CSP is deliberately not added here. It is tracked in Security: single-page docs are rendered with raw HTML enabled and re-hosted same-origin without a CSP #42, where the inline <style> in Base.astro, the shadow-DOM compat styles and the mermaid bootstrap script can be accounted for — and where it can be tested against the reframed iframe. A CSP guessed at in this PR would break the fragment silently, which is the failure mode the existing X-Frame-Options test exists to prevent.
• /healthz set its content type with an add_header placed after return 200, which never applies. Now default_type.

The image — #53

• Runs as UID 101 via nginxinc/nginx-unprivileged instead of a root master process. The container serves static files on 8080 and never needed the privilege. Confirmed in the running container: uid=101(nginx), no root process in ps.
• Pinned by digest, matching how every GitHub Action in .github/workflows/ is already pinned. Dependabot bumps the tag; the digest stops the deployment moving underneath it meanwhile.
• The stock config is overwritten rather than RUN rm-ed — a non-root image cannot delete files under /etc/nginx.
• dist/ staleness guard. dist/ is built outside the image and is not reproducible from the Dockerfile alone. Rather than convert to a multi-stage build — which would break the deploy pipeline's ability to build the image from a CI-produced dist/ artifact — the build now fails loudly when dist/ lacks index.html or style.css, instead of shipping an image that 404s.

New CI job

image — builds the runtime image from the build job's dist/ artifact and scans it with Trivy. npm audit covers JS dependencies only; nothing in CI looked at the base image, which is what the digest pin exists to control. CRITICAL-only and ignore-unfixed, so a routine base-image CVE does not block unrelated PRs; the fix when it does fire is to bump the pinned digest. The job doubles as proof that the Dockerfile's dist/ guards pass on a real build.

Verification

npm run build:headless                                → 8 apps integrated
npm test                                              → 57 passed  (was 49; +8 new)
npx playwright test --config=playwright.config.ci.js  → 20 passed  (was 15; +5 new)
docker build                                          → image builds, guards pass
docker exec … nginx -t                                → syntax ok

New tests/nginx-config.spec.js asserts nginx.conf as text, because no nginx runs anywhere in CI — the E2E suites hit tests/fragment-server.mjs, an Express mirror of the rewrites. It checks that every location declaring an add_header also includes the shared snippet, that the shared set is defined in exactly one place, that X-Frame-Options is not DENY, and that X-XSS-Protection is absent. Confirmed the guard reports exactly the two originally-broken blocks when the includes are removed.

tests/fragment-server.mjs now mirrors the header set too, so the five new assertions in standalone.spec.js are not vacuous — the two existing X-Frame-Options tests had been passing against a server that sent no headers at all.

Noticed, not fixed

location ^~ /knowledge-base/ takes precedence over the regex asset block, so the expires 1y; immutable policy never applies to knowledge-base assets — they get no-transform instead. Pre-existing, unrelated to the header bug, and changing it is a caching behaviour change rather than a fix. Worth its own issue; interacts with the style.css caching point already raised in #50.

Closes #45
Closes #53