Deferred Security Issues

These items were identified during a security review on 2026-05-02 and consciously deferred. Must be addressed before opening the application to a larger or public userbase.

1. Session credentials in URL query parameters (logged-in users)

Files: src/models/calendar/events/events.router.ts — all GET/PUT/DELETE handlers

sessionId and sessionKey are currently read from query parameters, which means they appear in server access logs, browser history, proxy logs, and Referer headers.

Fix: Move to request headers (X-Session-Id / X-Session-Key) or the request body. Requires a corresponding frontend update.

Note: the shared calendar password parameter in query params is intentional (iCal clients don't support headers) and is acceptable for the current setup.

2. No event ownership check

Files: src/models/calendar/events/events.router.ts

PUT /:eventId (update)
PUT /move/:eventId (move)
DELETE /:eventId (delete)

Currently any active user can edit, move, or delete any event regardless of who created it. This is acceptable while all users are trusted admins.

Fix: When non-admin users are introduced, fetch the event first and verify event.createdById === user.userId before allowing the mutation. Add an isAdmin flag to the user model to let admins bypass the check.

3. Activation token has no expiry

File: src/models/calendar/users/users.service.ts — createUser / activateUser

The email activation link is valid indefinitely. Acceptable for a small, trusted userbase.

Fix:

Add an activation_expires column to the users table (e.g. DATETIME).
Set it to NOW() + INTERVAL 24 HOUR in createUser.
Check activation_expires > NOW() in activateUser before accepting the token.

4. Password reset token has no expiry

File: src/models/calendar/users/users.service.ts — initiatePasswordReset / finalizePasswordReset

The reset token stored in pw_reset_token_hash never expires. Acceptable for a small, trusted userbase.