Enforce a strict browser execution boundary for the dashboard #295

Closed
opened 2026-08-08 11:32:05 +00:00 by rockachopa · 0 comments
Member

Problem

The authenticated dashboard has no browser execution boundary. Its large inline bootstrap and numerous dynamic rendering paths mean a future XSS regression could execute same-origin privileged actions using the operator session. The app also permits framing and lacks baseline browser hardening headers.

Vertical slice

Extract the dashboard bootstrap and stylesheet into same-origin static assets, enforce a strict nonce-free Content Security Policy with script-src 'self', add anti-framing and browser hardening headers to every response, and keep the complete PWA shell available offline.

Acceptance tests

  • Dashboard, login, health, authenticated API, and authentication error responses include CSP, X-Content-Type-Options, Referrer-Policy, Permissions-Policy, and anti-framing headers.
  • CSP contains script-src 'self', object-src 'none', and frame-ancestors 'none', with neither unsafe-inline nor unsafe-eval for scripts.
  • Dashboard HTML has no inline executable script; existing behavior initializes from a same-origin static asset.
  • The extracted CSS and JavaScript are included in the service-worker shell and remain available after an offline reload.
  • Root and configured subpath asset routing continue to work; full test suite passes.

Evidence / non-duplication

Current origin/main (54029d2) has a ~2,965-line inline dashboard script and no CSP/security-header middleware. A search of all 150 historical issues and recent/full commit concepts found no CSP, clickjacking, framing, or security-header delivery. Existing security tickets cover sessions, CSRF, throttling, fail-closed configuration, and cache control, not browser execution policy.

## Problem The authenticated dashboard has no browser execution boundary. Its large inline bootstrap and numerous dynamic rendering paths mean a future XSS regression could execute same-origin privileged actions using the operator session. The app also permits framing and lacks baseline browser hardening headers. ## Vertical slice Extract the dashboard bootstrap and stylesheet into same-origin static assets, enforce a strict nonce-free Content Security Policy with `script-src 'self'`, add anti-framing and browser hardening headers to every response, and keep the complete PWA shell available offline. ## Acceptance tests - Dashboard, login, health, authenticated API, and authentication error responses include CSP, `X-Content-Type-Options`, `Referrer-Policy`, `Permissions-Policy`, and anti-framing headers. - CSP contains `script-src 'self'`, `object-src 'none'`, and `frame-ancestors 'none'`, with neither `unsafe-inline` nor `unsafe-eval` for scripts. - Dashboard HTML has no inline executable script; existing behavior initializes from a same-origin static asset. - The extracted CSS and JavaScript are included in the service-worker shell and remain available after an offline reload. - Root and configured subpath asset routing continue to work; full test suite passes. ## Evidence / non-duplication Current `origin/main` (`54029d2`) has a ~2,965-line inline dashboard script and no CSP/security-header middleware. A search of all 150 historical issues and recent/full commit concepts found no CSP, clickjacking, framing, or security-header delivery. Existing security tickets cover sessions, CSRF, throttling, fail-closed configuration, and cache control, not browser execution policy.
timmy was assigned by rockachopa 2026-08-08 11:32:05 +00:00
Sign in to join this conversation.
No Milestone
No project
No Assignees
1 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: stackchain/stackchain-dashboard#295
No description provided.