Security model
Backlog Hold'em currently uses lightweight room identity suitable for an internal MVP or local demonstration.
Trust model
- A room is discoverable by its six-character invite code.
- Create/join returns an opaque participant ID.
- The browser stores that ID in
localStorageper room. - HTTP commands provide it in
X-Participant-ID. - WebSocket sessions provide it as a query parameter.
- The domain checks whether that participant belongs to the room and whether they are the facilitator.
- Public room snapshots hide every current vote value and revision count until reveal.
What is protected
Vote secrecy is enforced in the backend by Room.PublicCopy, before data reaches SSE or WebSocket adapters. The UI does not receive other participants' hidden values or revision counts. Revealed history and the final session summary are available to anyone who can read the room by code.
Facilitator-only operations are checked by domain methods rather than by button visibility alone.
Current limitations
- Participant IDs are bearer tokens but are not signed, rotated, or expired.
- Room reads and SSE streams require only the room code.
- WebSocket origin checking currently allows all origins.
- There are no user accounts, organization boundaries, CSRF tokens, rate limits, or audit records.
- WebSocket query parameters may appear in proxy logs.
- Display names and topics are length-limited only in selected domain paths; API-wide validation is minimal.
Before internet exposure
- Replace local-storage participant IDs with secure, HTTP-only session cookies or OIDC-backed sessions.
- Authorize room reads and real-time subscriptions.
- Restrict allowed WebSocket origins.
- Add CSRF protection for cookie-authenticated commands.
- Add request/body limits consistently, rate limiting, and structured audit events.
- Configure TLS and redact credentials/query strings from logs.
The single application image runs as the distroless nonroot user. TLS and public ingress policy remain responsibilities of the hosting platform.