src/lib/backend/session.ts defines SESSION_COOKIE_NAME = 'cl_session' and src/lib/backend/sessionCookies.ts's applySessionCookie() sets it as an HttpOnly cookie with CSRF-token rotation (rotateCsrfToken) — a complete, more secure session design. However, applySessionCookie (and everything else exported from sessionCookies.ts) is referenced nowhere outside its own definition file: a repo-wide search finds no route ever imports or calls it. The actual login endpoint, POST /api/auth/verify (src/app/api/auth/verify/route.ts), never sets any cookie at all — it only returns sessionToken in the JSON response body, and the client (src/hooks/useWallet.ts) is left to manually persist it, including setting a plain, non-HttpOnly document.cookie = "session=..." (already flagged elsewhere for the XSS/token-theft risk that creates). Separately, src/lib/backend/requireAuth.ts's requireAuth() reads a cookie literally named 'session' — matching that insecure client-set cookie, not cl_session — so it happens to "work" with the insecure path while the properly-designed HttpOnly cl_session system sits completely dead. Acceptance criteria: wire /api/auth/verify to call applySessionCookie and issue the HttpOnly cl_session cookie as the actual session mechanism, update requireAuth/GET /api/auth/csrf to read from it, and stop useWallet.ts from setting its own insecure session cookie — or, if session.ts/sessionCookies.ts was superseded by the auth.ts design, delete the dead HttpOnly-cookie code so it doesn't mislead contributors into thinking sessions are HttpOnly-protected today.
src/lib/backend/session.ts defines
SESSION_COOKIE_NAME = 'cl_session'and src/lib/backend/sessionCookies.ts'sapplySessionCookie()sets it as an HttpOnly cookie with CSRF-token rotation (rotateCsrfToken) — a complete, more secure session design. However,applySessionCookie(and everything else exported fromsessionCookies.ts) is referenced nowhere outside its own definition file: a repo-wide search finds no route ever imports or calls it. The actual login endpoint,POST /api/auth/verify(src/app/api/auth/verify/route.ts), never sets any cookie at all — it only returnssessionTokenin the JSON response body, and the client (src/hooks/useWallet.ts) is left to manually persist it, including setting a plain, non-HttpOnlydocument.cookie = "session=..."(already flagged elsewhere for the XSS/token-theft risk that creates). Separately, src/lib/backend/requireAuth.ts'srequireAuth()reads a cookie literally named'session'— matching that insecure client-set cookie, notcl_session— so it happens to "work" with the insecure path while the properly-designed HttpOnlycl_sessionsystem sits completely dead. Acceptance criteria: wire/api/auth/verifyto callapplySessionCookieand issue the HttpOnlycl_sessioncookie as the actual session mechanism, updaterequireAuth/GET /api/auth/csrfto read from it, and stopuseWallet.tsfrom setting its own insecuresessioncookie — or, ifsession.ts/sessionCookies.tswas superseded by theauth.tsdesign, delete the dead HttpOnly-cookie code so it doesn't mislead contributors into thinking sessions are HttpOnly-protected today.