fix(security): derive team session host identity from the authenticated session (Closes #105)

[SakethSumanBathini]

Closes #105

Problem

POST /team-sessions/create takes createdBy straight from req.body and hands it to teamSessionStore.createSession(), which uses it to populate hostName and hostLogin:

hostName: createdBy?.name || createdBy?.login || 'Host',
hostLogin: createdBy?.login || '',

Those two fields are what every participant joining the room sees attributed to its host. Because they originate in the request body, any authenticated user can create a team session presenting as any name and login they choose.

Both named files needed the fix, and here's why

The endpoint is registered twice:

• backend/src/routes/system.routes.ts (line 91)
• backend/src/routes/team.routes.ts → backend/src/controllers/team.controller.ts

In server.ts, createSystemRouter() mounts at line 96 and createTeamRouter() at line 104. Express matches in registration order, so the system route is the live handler and team.controller.createTeamSession is currently unreachable for this path. (Its GET /team-sessions/:code sibling in the same controller is live.)

Fixing only the reachable copy would leave a spoofable handler sitting one mount-order change away from being live again, so both are corrected identically.

Change

Both handlers now ignore createdBy from the body entirely and build it from req.authSession.user:

const sessionUser = req.authSession?.user;
if (!sessionUser?.login) {
  return res.status(403).json({ error: 'An authenticated user session is required to host a team session' });
}

const session = await teamSessionStore.createSession({
  repo,
  createdBy: { login: sessionUser.login, name: sessionUser.name || sessionUser.login },
});

The explicit 403 covers the bearer-token path: requireAccessToken accepts a raw bearer token and leaves req.authSession null, and a session hosted under an unverifiable identity is exactly what this change exists to prevent.

Compatibility

This is behaviour-preserving for real clients. EditorPage.tsx already sends createdBy: { login: userData?.login, name: userData?.name } built from its own session-derived user, and calls the API with credentials: 'include', so the cookie session is present and server-side derivation yields the same values it was sending.

Local test mode is also unaffected — localTestRepoService.getUser() returns { login: 'local-tester', name: 'Local Test User' }, so the session user is populated there too.

No frontend change is required; the now-ignored createdBy in the request body is harmless to leave in place.

Verification

• npx tsc --noEmit in backend/ clean.
• Both registration sites and the mount order in server.ts traced to confirm which handler is live.
• Confirmed createSession() reads only .name and .login off createdBy, so the substituted object is complete.

Note: npm test is red on clean main independently of this branch.

[coderabbitai]

Warning

Review limit reached

@SakethSumanBathini, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 14 minutes

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 8a57d290-9f01-4507-9c0a-ecd9b534e577

📥 Commits

Reviewing files that changed from the base of the PR and between 2f06e6e and 84318f5.

📒 Files selected for processing (2)

• backend/src/controllers/team.controller.ts
• backend/src/routes/system.routes.ts

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

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