SEC-HARDEN-001: Complete wallet, guest-session, WebSocket, CSP, and abuse-control hardening

[jamalfrnk]

Problem

SEC-017 (issue #21, PR #24) already covers nonce replay/expiry, cross-user ownership, and rate-limit enforcement for the existing wallet-only auth model. This mission adds guest sessions (AUTH-GUEST-001), multi-provider wallet selection (WALLET-001), and resource-intensive new endpoints (BACKTEST-001) that need their own hardening pass plus repo-wide CSP/header/abuse controls not yet addressed.

Repository evidence

Existing security docs (docs/security/SECURITY_BASELINE.md, SECURE_DEVELOPMENT_CHECKLIST.md) cover the pre-mission wallet-only surface; no CSP/security-headers middleware found in server.ts; no backtest-specific resource limits exist (backtesting doesn't exist yet).

Risk

P0 -- security hardening for newly introduced surfaces (guest sessions, multi-wallet, backtest compute) is release-blocking by definition.

Scope

Guest-session security (forgery/isolation), wallet-selection security (address normalization across providers), WebSocket authorization/origin handling for any new channels, security headers (CSP, frame restrictions, referrer policy, MIME-sniffing protection, transport security), backtest resource-exhaustion controls (date-range limits, candle-count limits, concurrency limits, request rate limits, timeout/cancellation, ownership checks, entitlement-limit enforcement per MONETIZE-001), dependency vulnerability scan, secret scan, sensitive-logging audit across every new module this mission introduces.

Non-goals

Not re-litigating SEC-017's already-covered wallet-only surface -- extend, don't duplicate.

Dependencies

AUTH-GUEST-001, WALLET-001, BACKTEST-001 (needs their surfaces to exist to harden them); should run late in the sequence per mission's recommended order.

Proposed implementation

Add a security-headers middleware (helmet-equivalent, hand-rolled or a minimal dependency, evaluated for necessity); backtest-specific rate-limit/concurrency middleware reusing the existing apiLimiter pattern; guest/wallet session cross-isolation tests.

Acceptance criteria

All newly introduced surfaces pass the same rigor bar as SEC-017's existing suite; backtest endpoint rejects oversized/over-concurrent requests with clear errors; security headers present on every response; no secrets in logs across any new module.

Definition of done

Full server test suite (extending the existing 150) passes with new security tests included; reviewer PASS with explicit security sign-off.

Test plan

Guest-session forgery/isolation, wallet address-normalization edge cases across providers, backtest resource-limit rejection (oversized range, too many concurrent requests, over-entitlement), CSP/header presence assertions, dependency/secret scan clean run.

Security review

This issue is the security review for the mission's new surfaces.

Accessibility review

N/A.

Observability requirements

Log rate-limit/resource-limit rejections by category and route.

Performance considerations

Security middleware (CSP/headers) must add negligible per-request overhead.

Rollback plan

Revert PR; underlying features (guest sessions, wallet, backtesting) still function, just without this hardening layer -- flag as an accepted risk if this needs to be temporarily rolled back.

Documentation requirements

Extend docs/security/SECURITY_BASELINE.md and SECURE_DEVELOPMENT_CHECKLIST.md; new docs/security/threat-model.md.

Completion evidence

(added on merge)

Reviewer verdict

(pending)