Enable RLS on push_dispatch_queue and host_join_notification_batches - #75
Open
bingb0t5 wants to merge 1 commit into
Open
Enable RLS on push_dispatch_queue and host_join_notification_batches#75bingb0t5 wants to merge 1 commit into
bingb0t5 wants to merge 1 commit into
Conversation
Supabase's security advisor flagged these two tables as rls_disabled_in_public. Every other public table in this project already has RLS enabled; these two were created by 20260407120000_add_web_push_notifications.sql and 20260412172000_batch_host_join_notifications.sql without an ENABLE line. Since Supabase grants anon and authenticated full CRUD on public tables by default, RLS being off let anyone with the public anon key read and write them over PostgREST. Confirmed live before the fix: an unauthenticated GET returned rows from push_dispatch_queue (5542), which exposes recipient_user_id and delivery traces, and anon held DELETE on the notification queue. No policies are added on purpose. Both tables are reached only by the push-dispatch edge function (service_role, which has BYPASSRLS) and by six SECURITY DEFINER functions owned by postgres, which run as the table owner and are exempt from RLS. FORCE ROW LEVEL SECURITY is deliberately not set, which is what preserves that exemption. Already applied to production on 29 Jul 2026 to stop the exposure; this migration records that change so the repo and the live database agree. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Deploying im-in with
|
| Latest commit: |
8056323
|
| Status: | ✅ Deploy successful! |
| Preview URL: | https://52aa169c.im-in.pages.dev |
| Branch Preview URL: | https://security-enable-rls-push-dis.im-in.pages.dev |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
Enables Row-Level Security and revokes the default
anon/authenticatedgrants on the two public tables that were missing it in the I'm In project (qxktbdjzhctfxnafiaxk).This was already applied to production on 29 Jul 2026 to stop an active exposure. This PR records the change so the repo and the live database agree.
Why
Supabase's security advisor flagged both as
rls_disabled_in_public. Supabase grantsanonandauthenticatedfull CRUD on public tables by default, so with RLS off anyone holding the public anon key could read and write them over PostgREST.Confirmed live before the fix: an unauthenticated
GETwith only the anon key returned rows frompush_dispatch_queue(5,542 rows), exposingrecipient_user_id,last_erroranddelivery_trace.anonalso heldDELETEon the notification queue, so the whole pending push pipeline could have been wiped.Every other public table in this project already has RLS enabled. These two were introduced without an
ENABLEline by:20260407120000_add_web_push_notifications.sql→push_dispatch_queue20260412172000_batch_host_join_notifications.sql→host_join_notification_batchesWhy no policies
Both tables are reached only by the
push-dispatchedge function (service_role, which hasBYPASSRLS) and by theseSECURITY DEFINERfunctions owned bypostgres, verified against the live catalog:enqueue_notification_for_push_dispatchenqueue_host_join_notification_batchflush_host_join_notification_batchesinvoke_host_join_batch_flushrequeue_stale_push_dispatch_jobsget_my_push_diagnosticsDefiner functions run as the table owner and are exempt from RLS, so the notification pipeline is unaffected.
FORCE ROW LEVEL SECURITYis deliberately not set, which is what preserves that exemption.Verification (post-apply, against production)
GETon both tables:401 permission denied.GETonpush_dispatch_queue: still returns 5,542.FORCE ROW LEVEL SECURITY: 0 tables.Note on root cause
34 of 36 tables had RLS; these two slipped through because nothing verifies schema end state after a migration merges. A CI check that fails when any public table has RLS off would have caught this in April.
Separately, 12 tables here have RLS on but zero policies (
event_private_audience_log1,351 rows,public_moderation_log_entries366, others). Those are already deny-by-default so they are not a hole, but worth a look to confirm each is intentional.🤖 Generated with Claude Code