Update the deferred-security advice for the cutover

DEFERRED_SECURITY.md item 1 still told the calendar to move its session
credentials from query parameters into X-Session-Id/X-Session-Key. That
was the right advice when two other modules read those headers; both
stopped in the cutover, so following it now would build a second
mechanism just as the first is being retired. The fix is the shared
admin identity, which closes the item outright rather than moving the
credential somewhere safer.

Also annotates the one assertion in auth-binding.ts that cannot
currently fail. It is kept deliberately - it is a tripwire against
someone reintroducing a header-session fallback for calendar users who
have not been invited yet, which is the shortcut this whole step exists
to close - but that was worth saying out loud rather than leaving it to
look like an oversight.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
2026-09-06 14:44:27 +02:00
parent 2405625f99
commit 9811610d55
2 changed files with 18 additions and 1 deletions
+13 -1
View File
@@ -11,7 +11,19 @@ These items were identified during a security review on 2026-05-02 and conscious
`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.
**Fix (updated 2026-09-06):** Move the calendar onto the shared admin identity -
`requireAppAccess('calendar')` against the better-auth session cookie, per
`docs/calendar-auth-migration.md`. That closes this item outright rather than moving the
credential to a safer place, and it is now the cheaper of the two: the feedback and tickets
modules made the same move on 2026-09-06 for one line each.
~~Move to request headers (`X-Session-Id` / `X-Session-Key`) or the request body.~~ No longer
the recommendation. Nothing on the server reads those two headers any more - the calendar's
query parameters are the last legacy credential path in the API - so this would build a second
mechanism just as the first is being retired. They survive only in the CORS `allowedHeaders`
list, and only until both frontends are redeployed.
Either fix 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.