fix: enable strict baseline Content-Security-Policy in Helmet - #380
Conversation
Helmet was registered with contentSecurityPolicy: false, disabling CSP entirely and leaving any XSS reaching the browser without a second line of defence. Enable a strict CSP locking every directive to 'none' — the manager is a JSON API and serves no application HTML — and let the one HTML surface, the Swagger UI at /api/docs, emit its own compatible CSP via swagger-ui's staticCSP option so the docs page keeps working. Closes #237 Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
|
Automated code review (daily-backlog-pr, self-authored PR) — Needs Changes The change itself is correct: the strict global Helmet CSP genuinely hardens the JSON API, and swagger-ui's Blocking:
Suggestions (non-blocking): optionally add explicit Moving the board item back to Ready; the regression test will be added on the next implementation pass. |
|
Automated code review (daily-backlog-pr, self-authored PR) — LGTM Reviewed by a separate code-reviewer invocation against the project criteria. The strict Helmet CSP baseline ( Blocking: None. Warnings: None. Suggestions were optional hygiene only (e.g. adding the standard |
Summary
contentSecurityPolicy: false, disabling CSP entirely (src/api.ts). Any XSS reaching the browser had no second line of defence.default-src,base-uri,form-actionandframe-ancestorsto'none'. The manager is a JSON API and serves no application HTML, so the policy can be fully restrictive./api/docs— now emits its own compatible CSP via swagger-ui'sstaticCSP: true, which overrides the strict global policy on that route so the docs page keeps rendering.Test plan
npm test— 363 passed)npm run typecheck)npm run linton changed file)/api/docs(Swagger UI) still renders in a browser under the new CSP, and that API responses carry the strictContent-Security-PolicyheaderCloses #237
🤖 Generated with Claude Code