[Medium][server] Session and CSRF cookies are not Secure by default #169

Severity: 🟡 Medium (insecure default; direct credential-theft impact)

Location

• Session cookie: src/server/session.ts:301-306 (and destroy path :336-343)
• CSRF secret cookie: src/server/csrf.ts:159-163

Description

The session-id cookie defaults to { httpOnly: true, sameSite: 'lax', path: '/' } with no secure:

const baseCookie: ServerCookieOptions = {
  httpOnly: true,
  sameSite: 'lax',
  path: '/',
  ...options.cookie,
};

The cookie holds the signed session id — the sole bearer credential for the session. On any deployment reachable over plain HTTP (mixed HTTP during redirect, or behind a misconfigured proxy), the cookie is transmitted in cleartext and can be captured by a network MITM, yielding full session hijack. sameSite: 'lax' does not compensate. The behaviour is documented ("Set secure: true in production"), but insecure-by-default for a session credential is a real trap for anyone who doesn't read the note.

The CSRF secret cookie (csrf.ts) has the same default ({ sameSite: 'lax', path: '/' }, no secure); in signed mode the token embeds the raw secret, so a MITM over HTTP can read it and forge matching tokens.

Suggested fix

Default secure: true and let users explicitly opt out for local HTTP dev, e.g. secure: options.cookie?.secure ?? true; or auto-enable Secure when the request/base URL is https:. Apply consistently to both the session and CSRF cookies. Consider promoting __Host- guidance from a doc note to a runtime default.

Filed as part of a full-codebase security & correctness audit.