Skip to main content
This lesson walks through auditing cookie and session security in an existing Node/Express codebase. We’ll use an automated reviewer (Claude Code for Beginners) that runs focused prompts against the repository to inspect session configuration, cookie flags, CSRF protection, session storage, and relevant route handlers. The goal is a concise, actionable security report with remediation examples you can apply. Below is a sample of the interactive reviewer CLI output while it loads prompts and inspects the repo. (The prompts themselves are large and stored separately.)
A screenshot of a code editor (VS Code) open to a markdown file titled “Session and Cookie Security Audit Report,” containing audit notes and a todo checklist. The project file explorer and side panels are visible on a dark blue themed interface.
Overview of review scope
  • Inspect session configuration: secure flag, HttpOnly, SameSite, session timeout, and session regeneration.
  • Validate cookie usage: flags, absence of sensitive data, domain/path scoping, and encryption of sensitive cookies.
  • Check for CSRF protections: token-based or double-submit cookie patterns, or origin/header checks.
  • Review session storage: avoid default in-memory stores in production; prefer Redis or DB-backed stores and ensure cleanup/expiration.
  • Produce a structured findings report: title, severity, CWE mapping, evidence, impact, exploitability, PoC (when safe), and code-level remediation.
Quick scope table Executive summary (condensed)
  • Authentication design: JWTs are used via Authorization headers — no traditional cookie-based session store is present.
  • Risk score: 8.5 / 10 (High) — main issues are lack of token revocation, absence of refresh token rotation, and limited guidance for secure token storage.
  • High-level remediation: introduce token revocation (blacklist), rotate and shorten JWT lifetimes, add refresh tokens stored securely (prefer httpOnly cookies), validate/enforce a strong JWT secret, and add CSRF protections if cookies are introduced.
Critical findings and recommended remediations
  1. No session management / token revocation (Critical — CWE-613)
  • Evidence: server.js:1-19, routes/auth.js:1-98 — JWTs are issued and there is no blacklist or revocation layer.
  • Impact: Stolen tokens remain valid until expiry; no immediate revocation path.
  • Exploitability: High — attackers with tokens can access resources until expiry.
Remediation (Redis-backed blacklist example)
Middleware to block blacklisted tokens:
  1. Missing refresh token implementation and long-lived access tokens (High — CWE-613)
  • Evidence: routes/auth.js:48-57 — only access tokens are issued; no refresh tokens are present.
  • Impact: Long-lived access tokens increase exposure windows. Refresh tokens allow shorter access token lifetimes and controlled re-authentication.
Server-side sketch for refresh tokens:
Refresh endpoint (rotate refresh token on use):
  1. No CSRF protection for cookie usage (Medium — CWE-352)
  • Evidence: server.js:1-19 — no CSRF middleware detected. Currently, JWTs in Authorization headers are not vulnerable to CSRF, but storing refresh tokens in cookies would require CSRF mitigation.
  • Impact: Cookies are automatically sent by browsers; without CSRF protections, state-changing endpoints can be abused.
Remediation example using csurf:
  1. Insecure or weak JWT secret handling (High)
  • Evidence: .env or code contains default or short JWT secret.
  • Impact: Weak or known JWT secrets let attackers forge tokens.
  • Exploitability: High if a default/short secret is used.
Remediation: enforce strong random secrets (≥ 32 chars) and check at startup:
For secret rotation, adopt a key-id (kid) strategy so older tokens can be validated during a transition period.
  1. No session/store configuration (Medium/High)
  • Evidence: no session store configured. If you adopt express-session for other parts, do not use MemoryStore in production.
  • Impact: MemoryStore leaks memory and lacks persistence and centralized invalidation.
Remediation (express-session + connect-redis):
  1. Token storage guidance missing (Medium)
  • Evidence: no client-side guidance or documentation. Storing JWTs in localStorage or sessionStorage is vulnerable to XSS.
  • Impact: JavaScript-accessible tokens can be exfiltrated via XSS.
  • Recommendation: Prefer storing refresh tokens in httpOnly cookies; keep access tokens short-lived and in memory. Provide client guidance for native and SPA clients.
Logout and revocation
  • Implement logout endpoints to:
    • Blacklist access tokens (as applicable), and/or
    • Delete/expire refresh tokens in the DB and clear refresh cookie.
  • Example logout handler:
Security checklist (condensed) Top priority fixes (recommended)
  1. Replace any weak/default JWT secret with a strong, randomly generated secret and enforce minimal length checks.
  2. Implement token blacklisting/invalidations (Redis or DB-backed) to support immediate revocation.
  3. Adopt a refresh-token architecture with short-lived access tokens and rotated refresh tokens stored as secure httpOnly cookies.
  4. Add logout endpoints that invalidate refresh tokens and optionally blacklist access tokens.
  5. If cookies are used, enable CSRF protection (e.g., csurf or double-submit) and ensure secure, httpOnly, and sameSite flags are set.
Proof-of-concept checks (examples)
  • Check for missing logout endpoint:
  • Confirm token remains valid after intended revocation (demonstrates lack of revocation):
Notes on audit methodology
  • Break audits into focused checks (cookie flags, CSRF, token management, secret handling) rather than issuing a single large prompt. Focused prompts reduce hallucinations and improve coverage.
  • Repeated findings across different, independent checks indicate a higher-confidence issue that needs remediation.
Final recommendations (roadmap)
  • Immediate: Replace weak JWT secret, add logout and token blacklist, shorten access token lifetime.
  • Week 1: Implement refresh-token rotation, persist refresh tokens in a DB, and set refresh cookie flags (httpOnly, secure, sameSite).
  • Week 2: Add CSRF protection for cookie-based flows, add session monitoring and adaptive timeouts.
  • Month 1: Harden secrets management, implement auditing and alerting for session anomalies, and map controls to compliance frameworks (OWASP Top 10, PCI-DSS, SOC 2, NIST).
If you adopt cookies for refresh tokens: always set httpOnly, secure (in production), and sameSite: 'strict', and pair this with CSRF protections for state-changing endpoints.
Subsequent content will cover file handling and business-logic security issues (file uploads, validation, and authorization checks).

Watch Video