Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Validate WebSocket subscribe payloads and cap rooms per client

Open
  • Is something wrong?
#393 4 comments 0 reactions 1 assignee View on GitHub

Maintainers usually reply within 1 day

@0xMegie is already working on this.

Since Sep 26, 2026.

Assessment

This issue has not been assessed yet.

Description

bug Stellar Wave

Description

Builds on #32 and #165. MilestoneNotificationsGateway (backend/src/milestone-notifications/milestone-notifications.gateway.ts) is a Socket.IO gateway; clients join and leave gig:<id> rooms. The premise that connections leak on disconnect is not supported by the code: the gateway keeps no per-client state of its own (no maps, listeners or timers), and Socket.IO removes a disconnected socket from all of its rooms automatically, so handleDisconnect only needs to log.

What is genuinely unbounded is what a single connection may do before it disconnects:

  • subscribe:gig calls client.join(gig:${data.gigId}) with no validation of data (a missing payload throws a TypeError), no format check on gigId, and no limit on how many rooms one socket can join. A client can create arbitrarily many, arbitrarily named rooms, growing server memory for as long as the connection is open.
  • The handshake is unauthenticated (no JWT check) and there is no cap on concurrent connections, so the above is available to anyone.
  • There is no visibility into open connections or room counts, so any real growth could not be spotted.

(Separately, nothing in the app currently calls emitMilestoneUpdate / emitDeliverableUploaded, and nothing subscribes to the outbox trustflow:events:gateway Redis channel; that wiring is out of scope here.)

Component

Backend

Difficulty

🟡 Medium

Tasks

  • Validate the subscribe:gig / unsubscribe:gig payload (gigId present, matches the gig id format, length-limited) and return an error ack instead of throwing
  • Cap the number of rooms a socket may join (configurable) and reject beyond it
  • Decide whether subscriptions need JWT authentication at handshake; if so, implement it with the existing JwtAuthGuard / AuthService.validateToken
  • Track connection count and rooms per gateway (log line or metric) and log disconnect reason
  • Unit tests for invalid payloads, room cap and disconnect behaviour

Acceptance Criteria

  • A single client cannot join unbounded or malformed rooms
  • Malformed subscribe payloads return an error response and never throw
  • Connection and room counts are observable
  • Covered by a gateway spec (there is none today)

Estimated Time

1-2 days

Dominant language
TypeScript
Stars
0
Forks
58
Avg merge
3h 5m
Merged PRs (30d)
44

Getting set up

  • Ships a Dockerfile or Docker Compose file
  • Has a pull request template
  • No contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from trustflow-protocol/trustflow-backend

All issues in trustflow-protocol/trustflow-backend

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.