-
Notifications
You must be signed in to change notification settings - Fork 0
feat: frontend security hardening (post-app-shell) #820
Copy link
Copy link
Closed as not planned
Labels
prio:highImportant, should be prioritizedImportant, should be prioritizedscope:medium1-3 days of work1-3 days of worktype:featureNew feature implementationNew feature implementationv0.5Minor version v0.5Minor version v0.5v0.5.1Patch release v0.5.1Patch release v0.5.1
Description
Context
PR #819 (app shell) established the frontend auth/routing foundation. Security review identified several improvements that require backend changes or are preventive for future pages.
Items
1. Migrate JWT from localStorage to httpOnly cookies
- Why: localStorage is accessible to any JS in the page context (XSS token theft). httpOnly cookies eliminate this attack surface entirely.
- Requires: Backend cookie-based auth support, CSRF token middleware, SameSite cookie attributes, CORS
credentials: includeconfig. - Current mitigation: CSP
script-src 'self', short-lived tokens with auto-expiry, 401 interceptor cleanup. Documented inweb/src/api/client.tsanddocs/security.md.
2. ESLint rule to ban dangerouslySetInnerHTML
- Why: When pages render user-controlled content (agent names, task titles, messages, provider labels), XSS becomes the primary risk vector. A lint rule catches accidental usage at write time.
- Action: Add
no-restricted-syntaxoreslint-plugin-reactrule to flagdangerouslySetInnerHTMLfor mandatory review. Allow with explicit// eslint-disable-next-line+ justification comment.
3. Remove CSP style-src 'unsafe-inline'
- Why: Permits CSS injection for data exfiltration if secrets are rendered in the DOM (e.g., API keys in settings form).
- Blocked by: Radix UI and Framer Motion inject dynamic inline styles. Revisit when they support nonce-based or hash-based CSP.
- Location:
web/security-headers.confline 9.
4. Validate ?returnTo= parameter on LoginPage
- Why: PR feat: app shell, Storybook, and CI/CD pipeline #819 adds
sessionStoragereturn path saving (S3 fix). When the LoginPage form is built, the redirect-after-login must validate: starts with/, does not start with//, contains no protocol scheme. Reject anything else and default to/. - Timing: When LoginPage is implemented (likely feat: analytics trends and budget forecast API endpoints #771 or auth page issue).
5. Backend setup endpoint idempotency enforcement
- Why:
SetupCompleteGuardis client-side defense-in-depth. The backend/api/v1/setupendpoint must independently reject re-initialization when setup is already complete. - Timing: When setup wizard backend is implemented.
References
- Security review from PR feat: app shell, Storybook, and CI/CD pipeline #819
web/src/api/client.tsSECURITY NOTE (lines 19-28)web/security-headers.confdocs/security.md
Reactions are currently unavailable
Metadata
Metadata
Assignees
Labels
prio:highImportant, should be prioritizedImportant, should be prioritizedscope:medium1-3 days of work1-3 days of worktype:featureNew feature implementationNew feature implementationv0.5Minor version v0.5Minor version v0.5v0.5.1Patch release v0.5.1Patch release v0.5.1