fix: Missing support for cookieSessionSecret in config file for multi-replica deployments

[Copilot]

New Pull Request Checklist

• I am not disclosing a vulnerability.
• I am creating this PR in reference to an issue.

Issue Description

Multi-replica deployments behind load balancers fail with "CSRF token validation failed" errors. This is a regression from before v8.x where configurations that worked previously stopped functioning. When cookieSessionStore was added in v8.x with config file support, cookieSessionSecret was not given equivalent config file support, creating an inconsistency that broke multi-replica deployments relying on config file configuration.

Approach

This fix restores the ability to configure multi-replica deployments through config files by adding config file fallback for cookieSessionSecret to match cookieSessionStore behavior:

• server.js: Read from config.data.cookieSessionSecret when CLI/env not provided
• app.js: Read from config.cookieSessionSecret and config.cookieSessionStore when options not provided

Priority: CLI/env → options → config → random generation

Example config file:

{
  "apps": [...],
  "users": [...],
  "cookieSessionSecret": "shared-secret-across-replicas"
}

Example programmatic:

ParseDashboard({
  apps: [...],
  cookieSessionSecret: "shared-secret"  // Now reads from config if not in options
}, options);

TODOs before merging

• Add tests
• Add changes to documentation (guides, repository pages, in-code descriptions)

Original prompt

---

This section details on the original issue you should resolve

<issue_title>Regression: Getting CSRF token validation fails on Dashboard</issue_title>
<issue_description>### New Issue Checklist

• I am not disclosing a vulnerability.
• I am not just asking a question.
• I have searched through existing issues.
• I can reproduce the issue with the latest versions of Parse Server and Parse Dashboard.

Issue Description

When Parse Dashboard is deployed with multiple replicas behind a load balancer that does not provide sticky sessions, login attempts fail with the CSRF error message “CSRF token validation failed. Please refresh the page and try again.” The issue disappears immediately when all requests are routed to a single replica.

This is a regression on #3015. All the same description and repro steps are the same. I believe a fix was added in 8.1.0 to support a redis session store. But the old method of providing an environment variable for the cookieSessionSecret was not restored.

// worked prior to Parse Dashboard v8.x
export const dashboardOptions = {
  allowInsecureHTTP: true, // HTTPS terminated by NGINX so we have to allow this
  cookieSessionSecret: process.env.DASHBOARD_COOKIE_SESSION_SECRET, // required when hosted in a clustered environment
  trustProxy: 1, // Trust first proxy (required when behind load balancer/nginx)
};

Steps to reproduce

1. Deploy the Parse Dashboard behind a load balancer. I'm using AWS ELB running two instances of Parse + Dashboard.
2. Configure your dashboard using the old cookieSessionSecret method that worked prior to Parse Dashboard 8.0.
3. Access https:///dashboard/login, enter a configured username and password, then submit the form.
4. Observe the 403 response and the CSRF error message.

Actual Outcome

• Browser shows CSRF token validation failed. Please refresh the page and try again. after submitting the login form.

Expected Outcome

• login should succeed.

Environment

Dashboard

• Parse Dashboard version: 8.0.0
• Browser (Safari, Chrome, Firefox, Edge, etc.): Safari 18.1 / Chrome 129
• Browser version: Safari 18.1 (macOS 15.1) / Chrome 129.0.6668.90

Server

• Parse Server version: 8.5.0
• Operating system: Linux
• Local or remote host: AWS

System (MongoDB or Postgres): MongoDB
Database version: 7.0
Local or remote host: MongoDB Atlas

Logs

Relevant snippet with VERBOSE=1:

[error] CSRF token mismatch: EBADCSRFTOKEN (login POST)
</issue_description>

<agent_instructions>Verify that the issue exists and if so, implement a fix.</agent_instructions>

Comments on the Issue (you are @copilot in this section)

• Fixes Regression: Getting CSRF token validation fails on Dashboard #3051

---

✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.

[coderabbitai]

Important

Review skipped

Bot user detected.

To trigger a single review, invoke the @coderabbitai review command.

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

---

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

[parseplatformorg]

✅ Snyk checks have passed. No issues have been found so far.

Status	Scanner	Critical	High	Medium	Low	Total (0)
✅	Open Source Security	0	0	0	0	0 issues

💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse.

[mtrezza]

@copilot Verify your statement:

While v8.x added cookieSessionStore config file support, cookieSessionSecret remained CLI/env-only, creating an inconsistency.

In the issue, @chadpav describes it as working before, so this is not a feature addition but a bug fix, correct?

[parse-github-assistant]

🚀 Thanks for opening this pull request! We appreciate your effort in improving the project. Please let us know once your pull request is ready for review.

[Copilot]

@copilot Verify your statement:

While v8.x added cookieSessionStore config file support, cookieSessionSecret remained CLI/env-only, creating an inconsistency.
...

You're correct - this is a bug fix, not a feature addition. The issue describes a regression where multi-replica deployments that worked before v8.x stopped working.

The inconsistency I mentioned refers to the implementation detail: when cookieSessionStore was added (supporting config file usage), cookieSessionSecret was not given the same config file support, creating an asymmetry in how these related options were configured.

The user's code was passing cookieSessionSecret via options (which worked), but for consistency with cookieSessionStore and to support config-file-based deployments, this fix enables cookieSessionSecret to also be specified in the config file - restoring the ability to configure multi-replica deployments purely through config files as before.

Commit: 5ec933e

[mtrezza]

@chadpav can you test this out?

[chadpav]

@chadpav can you test this out?

I was able to verify locally but my deployment to prod fails. I think it's because I'm referencing a github branch for the dependency and I'm using AWS Elastic Beanstalk which might not like that. It tries to run npm install on deployment. So i can't actually verify fully.

Looking at the changes though, they are very minimal. I'd approve this and try to deploy the alpha release.

[mtrezza]

I was able to verify locally

How did you verify locally? I tried setting "cookieSessionSecret": "mySecret", in parse-dashboard-config.json, navigating to the login page, restarting with npm run dev and the login then failed with CSRF token validation failed. Please refresh the page and try again..

referencing a github branch for the dependency and I'm using AWS Elastic Beanstalk which might not like that.

There should be no issue with this. Let's first get this working before we merge.

[chadpav]

@mtrezza I created a TEST environment in AWS by cloning PROD. After a lot of troubleshooting, I believe the reason I had trouble deploying the branch vs. the NPM assets is that the Dashboard requires a webpack build step and AWS EB did not like that. That's based on working with Claude and webpack isn't something I've done a lot with so it could be off.

Anyway, I modified my TEST setup to allow me to npm install locally and include node_modules when i deploy and that got me around the issue.

However, I'm still getting the original error message so we might need to keep digging. I'm looking into the root issue now.

[chadpav]

I asked Claude to review this Github PR, the code, other issues, etc to help with a root cause analysis. It showed me that there were a lot of PR's recently around this issue and it's analysis sounds correct to me but I wanted to get your feedback on it. TLDR; the architecture has changed and we might not be able to support the old environment variable option.

---

The breaking change happened in v8.0.0 when the session middleware was switched from cookie-session to express-session.

• v7.x and earlier used cookie-session which stores all session data directly in the cookie (encrypted). With a shared cookieSessionSecret, this works across multiple instances because each instance can decrypt and validate the cookie independently.

• v8.0.0 switched to express-session which only stores a session ID in the cookie. The actual session data (including the CSRF token) is stored server-side in MemoryStore by default. Even with a shared secret, each instance has its own isolated memory, so a CSRF token created on Instance A doesn't exist on Instance B.

	cookie-session	express-session (default)
Session data location	In the cookie (encrypted)	Server-side MemoryStore
Multi-instance with shared secret	Works	Broken

The cookieSessionStore option added in #3016 / v8.1.0 allows you to provide a shared store (Redis, etc.), but this requires additional infrastructure and can't be configured via environment variables since it needs an instantiated object.

Potential fixes:

1. Revert to cookie-session for backward compatibility
2. Add a cookie-based session store option for express-session (like cookie-session behavior) that doesn't require external infrastructure
3. Document that multi-instance deployments now require either sticky sessions or a shared session store

The PR #3052 (copilot/fix-csrf-token-validation branch) restores config file support for cookieSessionSecret, but this doesn't solve the underlying issue since the secret only signs the session ID cookie—it doesn't help when session data lives in per-instance memory.

[mtrezza]

Makes most sense, if not too complex:

Add a cookie-based session store option for express-session (like cookie-session behavior) that doesn't require external infrastructure

Do you want to give it a try?

[chadpav]

I asked it about that and it points out that the cookie has moved from the client to the server with this change. So making a cookie-based session store is just going to use a shared secret to encrypt a unique cookie on each instance of the server.

I also learned that I can reuse my existing mongo db infrastructure as a session store via mongo-connect. I'm testing that out as an alternative to fixing this if you think it's going to be a big refactor. That addresses my bigger issue that I didn't want to stand up a new redis instance just for this.

[chadpav]

Using mongo as a session store and redeploying with 8.1.0 has resolved my original issue. It's an alternative to restoring the original behavior and I'm good with it.

1. do you think it's worth pursuing support of the original pre-8.0 behavior and having to support the complexity of two different configuration options for multi-instance support?

All Parse Server users are going to have a mongo or pg data layer and it's a pretty simple solution to configure a mongo/pg session store that doesn't require additional infrastructure.

2. Should we at least update release notes to flag a deprecated+breaking change?

[chadpav]

@mtrezza I was curious so I checked to see if the 8.0 release notes mentioned this breaking change already. After digging around, I think this slipped through the cracks and was never mentioned. The switch from cookie-session to express-session happened in the 7.6.0-alpha.9 release and 7.6.0 isn't released yet.

See this commit fbb5e6d which was about fixing something that seems unrelated fix: Security upgrade passport from 0.5.3 to 0.6.0.

This is a breaking change scheduled to affect 7.6.0, fyi. CC: @Moumouls

It also means the 7.6.0 and 8.0.0 will only work in single-instance deployments since you weren't able to configure your own session store until 8.1.0.

---

This is interesting reading.
fix(security): migrate from cookie-session to express-session

I even read the AI comments which correctly pointed out some issues:

• The AI reviewer suggested an improvement which ended up being what was implemented in 8.1.0. It suggested passing through session options to avoid the memory store in production.

To avoid MemoryStore in production, accept options.sessionStore and pass it to express-session. Based on learnings

Apply:

-  app.use(require('express-session')({
+  app.use(require('express-session')({
     name: 'parse_dash',
     secret: cookieSessionSecret,
     resave: false,
     saveUninitialized: false,
+    store: options.sessionStore || undefined,
     cookie: {
       maxAge: cookieSessionMaxAge != null ? Number(cookieSessionMaxAge) : undefined,
       httpOnly: true,
       sameSite: 'lax',
       secure: 'auto'
     }
   }));

• the AI correctly flagged the change when suggesting a new title:

Please revise the title to reflect the primary migration to express-session and the correct passport version, for example: “feat: migrate to express-session for authentication and bump passport to 0.7.0.”

fix(auth): migrate to express-session for authentication

P.S. - don't misread my intent here. I was just curious about how you guys are using AI to support this project so I was interested in what the AI was telling you. +1 for transparency. It's all good, this would be hard to catch unless you had a multi-instance system to test against. Running the project locally does not reproduce the issue. Also, the AI messages were mixed in with a bunch of other noise and I had the benefit of knowing exactly what the needle in the haystack looked like.