Harden session cookie with HttpOnly, Secure, SameSite, and maxAge

[advikdivekar]

What is the problem

backend/server.js configures express-session with no cookie options. This leaves the connect.sid session cookie without three critical security flags:

• No HttpOnly: JavaScript can read document.cookie and exfiltrate the session ID. Any XSS gadget in the app or a compromised npm dependency achieves full account takeover without knowing the user's password.
• No SameSite: The browser attaches the session cookie to cross-site requests automatically. A malicious page on any domain can issue credentialed requests to the backend (CSRF).
• No Secure: The cookie is transmitted over plain HTTP. A passive network observer or a man-in-the-middle on an HTTP connection captures the session ID.
• No maxAge: Sessions never expire on the client side, so a stolen cookie remains valid indefinitely.

What was changed

backend/server.js

• Added a cookie block to the express-session configuration with httpOnly: true, environment-aware secure and sameSite values, and a 24-hour maxAge.
• secure and sameSite are derived from process.env.NODE_ENV: in production they are true and 'strict'; in development they are false and 'lax' so that local HTTP development and top-level navigation redirects continue to work without disabling cookie behaviour entirely.

backend/Dockerfile.prod

• Added ENV NODE_ENV=production so the production cookie policy (Secure, SameSite=Strict) activates automatically in containerised production deploys without requiring a manually configured environment variable.

backend/.env.sample

• Added NODE_ENV=development so local developers set the variable explicitly and understand its effect on cookie behaviour.

Why this approach

Environment-aware cookie flags solve the practical problem that Secure: true rejects cookies on plain HTTP, which breaks local development. Using NODE_ENV to branch between strict/lax and true/false is the standard Express pattern and matches how the rest of the ecosystem handles this. Setting it in Dockerfile.prod rather than relying on external orchestration ensures the flag cannot be accidentally omitted in a production container.

maxAge bounds the attack window for any session ID that is already exposed before this patch is deployed.

How to test

1. Start the backend with NODE_ENV=development and log in. Open DevTools → Application → Cookies. connect.sid must show HttpOnly: ✓ and SameSite: Lax.
2. Run document.cookie in the browser console. The result must be an empty string (HttpOnly enforced).
3. Start the backend with NODE_ENV=production. After login, connect.sid must show HttpOnly: ✓, Secure: ✓, and SameSite: Strict.
4. Confirm the cookie has a 24-hour Max-Age / Expires value in the Set-Cookie header.

Edge cases covered

• sameSite: 'lax' in development permits OAuth and form-submission redirects while still blocking third-party POST CSRF.
• secure: false in development prevents silent cookie rejection when the dev server runs on HTTP, which would break the entire auth flow.
• maxAge is set to exactly 86400000 ms (24 hours) to bound the lifetime of a stolen session ID without forcing unreasonably frequent re-logins.

Verification

• Root cause fully resolved
• All edge cases handled
• No regressions — session-based authentication continues to work in both dev and prod environments
• Only the session config block in server.js is modified; the CORS block and route mounting are untouched
• Code matches project style and conventions

Labels: type:security level:intermediate gssoc:approved

Closes #373

Please assign this PR to me under GSSoC 2026.

[netlify]

✅ Deploy Preview for github-spy ready!

Name	Link
🔨 Latest commit	dea96f1
🔍 Latest deploy log	https://app.netlify.com/projects/github-spy/deploys/6a0f5f2b3c180d0008c50506
😎 Deploy Preview	https://deploy-preview-380--github-spy.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify project configuration.

[coderabbitai]

Warning

Rate limit exceeded

@advikdivekar has exceeded the limit for the number of commits that can be reviewed per hour. Please wait 50 minutes and 54 seconds before requesting another review.

You’ve run out of usage credits. Purchase more in the billing tab.

⌛ How to resolve this issue?

After the wait time has elapsed, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

We recommend that you space out your commits to avoid hitting the rate limit.

🚦 How do rate limits work?

CodeRabbit enforces hourly rate limits for each developer per organization.

Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout.

Please see our FAQ for further information.

ℹ️ Review info

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: ad7b2770-8d43-411c-9934-e93e6ff91f2d

📥 Commits

Reviewing files that changed from the base of the PR and between 9d34c19 and dea96f1.

📒 Files selected for processing (3)

• backend/.env.sample
• backend/Dockerfile.prod
• backend/server.js

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}