Why do private Realtime channels need their own RLS-style authorization check?

A Realtime Broadcast or Presence channel isn't backed by a specific table row the way a Postgres Changes event is — there's no underlying SELECT ... WHERE for Postgres's RLS engine to filter, because the "message" being sent might be an arbitrary payload like a cursor position or a chat line that never touches a table at all.

Without a dedicated authorization step, any client holding a valid JWT could subscribe to any channel name and both read and publish messages on it, since a channel name alone (like room-42) carries no inherent permission information the server can check against ordinary table policies. Requiring an explicit authorization check — typically a function that looks up whether the calling user is actually a participant in that room — closes that gap, making channel access something the application deliberately grants per user rather than something implied just by knowing (or guessing) a channel's name.

Invest now in Acorns!!! 🚀
Join Acorns and get your $5 bonus!

Acorns is a micro-investing app that automatically invests your "spare change" from daily purchases into diversified, expert-built portfolios of ETFs. It is designed for beginners, allowing you to start investing with as little as $5. The service automates saving and investing. Disclosure: I may receive a referral bonus.

Invest now!!! Get Free equity stock (US, UK only)!

Use Robinhood app to invest in stocks. It is safe and secure. Use the Referral link to claim your free stock when you sign up!.

The Robinhood app makes it easy to trade stocks, crypto and more.

Webull! Receive free stock by signing up using the link: Webull signup.