Add claude init file + refactor some security issues
This commit is contained in:
@@ -0,0 +1,55 @@
|
||||
# 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:**
|
||||
1. Add an `activation_expires` column to the `users` table (e.g. `DATETIME`).
|
||||
2. Set it to `NOW() + INTERVAL 24 HOUR` in `createUser`.
|
||||
3. 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.
|
||||
|
||||
**Fix:**
|
||||
1. Add a `pw_reset_expires` column to the `users` table (e.g. `DATETIME`).
|
||||
2. Set it to `NOW() + INTERVAL 15 MINUTE` in `initiatePasswordReset`.
|
||||
3. Check `pw_reset_expires > NOW()` in `finalizePasswordReset` before accepting the token.
|
||||
Reference in New Issue
Block a user