trackslash
TRACK-11 P2

Add a baseline browser security-header policy

0
All issues

Description

Problem

Global middleware currently sets request IDs, logging, recovery, dev reload, and optional CORS only (internal/server/server.go:55-74). UI rendering sets only Content-Type (internal/server/ui_templates.go:192-201). There is no Content-Security-Policy, frame restriction, HSTS, explicit Referrer-Policy, Permissions-Policy, or global X-Content-Type-Options.

The templates contain inline scripts/styles and third-party script loads, so introducing a meaningful CSP requires deliberate asset extraction/nonces rather than a superficial permissive header.

Impact

The application lacks defense-in-depth against script injection and third-party asset compromise, can be framed for clickjacking, and does not itself pin HTTPS behavior or referrer leakage policy. A future escaping regression would have a larger impact than necessary.

Acceptance criteria

  • Add centrally tested security headers for browser responses.
  • Enforce a useful CSP after localizing frontend assets: start with default-src 'self', restrict object-src, base-uri, form-action, and frame-ancestors, and avoid unsafe-eval.
  • Move inline executable code/styles to static assets or use per-response nonces/hashes rather than permanently allowing unrestricted inline execution.
  • Add X-Content-Type-Options: nosniff, a strict Referrer-Policy, and an appropriately minimal Permissions-Policy.
  • Emit HSTS only when the deployment is known to be HTTPS, with a documented rollout policy.
  • Add response tests for login, authenticated HTML, API/MCP JSON, attachments, and localhost development.

Sub-issues

0

Linked issues

0

GitHub

0

No branches or pull requests linked.

Comments

1