89ec509eb9
Parsed remaining medium-severity findings into 12 tasks + verification. Created docs/deferred-errors.md for MS-MED-006 (CSP) and MS-MED-008 (Valkey SSOT). Created Gitea issue #347 for Phase 4. Estimated total: 117K tokens. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
35 lines
2.2 KiB
Markdown
35 lines
2.2 KiB
Markdown
# Deferred Errors
|
|
|
|
Documented per Two-Phase Completion Protocol during Phase 3 Polish.
|
|
|
|
---
|
|
|
|
## MS-MED-006: SEC-WEB-16 - Add Content Security Policy Headers
|
|
|
|
- **File:** `apps/web/next.config.ts`
|
|
- **Error:** No Content Security Policy (CSP) headers configured
|
|
- **Category:** Architectural
|
|
- **Reason:** CSP requires extensive configuration specific to the deployment environment. Inline scripts from Next.js, third-party integrations (Authentik, Ollama), WebSocket connections, and dynamic imports all need careful allowlisting. A misconfigured CSP breaks the application in production. This needs a dedicated effort with staging environment testing.
|
|
- **Suggested approach:**
|
|
1. Audit all script sources, style sources, connect sources, and frame sources
|
|
2. Start with CSP report-only mode to capture violations without blocking
|
|
3. Add nonce-based script loading for Next.js inline scripts
|
|
4. Configure per-environment CSP (dev permissive, prod strict)
|
|
5. Add violation reporting endpoint
|
|
- **Risk:** Medium — Mitigated by other security controls (CSRF tokens, XSS sanitization, auth guards). CSP is defense-in-depth.
|
|
|
|
---
|
|
|
|
## MS-MED-008: CQ-ORCH-2 - Use Valkey as Single Source of Truth for Sessions
|
|
|
|
- **File:** `apps/orchestrator/src/spawner/agent-spawner.service.ts:19`
|
|
- **Error:** In-memory Map used for sessions alongside Valkey, creating dual source of truth
|
|
- **Category:** Architectural
|
|
- **Reason:** Migrating from in-memory Map to Valkey-only requires: (1) redesigning the session access pattern to be async everywhere, (2) handling Valkey connection failures gracefully, (3) ensuring atomic read-modify-write for state transitions, (4) updating ~20 call sites that currently access the synchronous Map. The in-memory Map is bounded by CQ-ORCH-1 (session cleanup on terminal states), reducing the unbounded growth risk.
|
|
- **Suggested approach:**
|
|
1. Add TTL-based expiry to Valkey session keys
|
|
2. Implement read-through cache pattern: Map as cache, Valkey as source
|
|
3. Add Valkey connection health check before spawn operations
|
|
4. Migrate call sites incrementally with feature flag
|
|
- **Risk:** Low — Bounded by CQ-ORCH-1 cleanup. Single-instance deployment means no cross-instance consistency issue.
|