profiles RLS lets a signed in user overwrite their own xp, level, and role directly

[jakharmonika364]

What happened?

The profiles_update_self policy (supabase/migrations/0001_initial_schema.sql, line 277) is:

create policy profiles_update_self on profiles for update
  using (auth.uid() = id);

This only restricts which row you can update, not which columns. Combined with the table grant authenticated gets in migration 0021 (grant select, insert, update, delete on all tables in schema public to authenticated), any signed in user can call the Supabase client directly from the browser, bypassing the app's own server actions in profile.ts entirely, and run something like:

update profiles set xp = 999999, level = 5, role = 'maintainer' where id = auth.uid()

There is no trigger or check constraint stopping writes to xp, level, role, or audit_completed.

Steps to Reproduce

1. Sign in as any user
2. Using the browser's own Supabase client and the user's session, call .from('profiles').update({ xp: 999999, level: 5 }).eq('id', <own id>)
3. The update succeeds with no server side validation at all

Expected Behavior

Sensitive columns like xp, level, and role should only be writable through server side logic (XP events, audits, admin actions), not via direct client updates, regardless of which row they target.

Where does this occur?

API / Database (RLS)

Additional Context

The simplest fix is probably a before update trigger on profiles that resets xp, level, role, and audit_completed back to their old values unless the request comes from the service role, since RLS alone can't cleanly express "this column only, only under these conditions" once a role already has broad table access.

[diksha78dev]

@Ayush-Patel-56 I would like to work on this issue under the GSSOC'26 and SSoC'26 programs.

Proposed Solution

To resolve this critical RLS bypass, I will implement a database-level safeguard using a PostgreSQL trigger.

• Action: Create a new migration in supabase/migrations/ to define a BEFORE UPDATE trigger function on the profiles table.
• Implementation:
  • Trigger Logic: The trigger will verify the current database role. If the request is not executed by the service_role, it will explicitly reject any attempt to modify sensitive columns (xp, level, role, audit_completed) by resetting them to their existing values (OLD.column).
  • Security: This ensures that even if RLS policies are misconfigured or overly permissive, the database itself prevents unauthorized modification of these protected fields.
  • Migration: Use the standard Supabase migration pattern to ensure this is applied atomically across all environments.
• Testing: I will perform a manual test using the Supabase client from a browser session (as documented in the reproduction steps) to verify that direct updates to these sensitive columns now fail or are silently ignored, while server-side updates via service_role continue to function.

[github-actions]

Hey @diksha78dev

You currently have 3 open issues assigned to you. The limit is 3 at a time.

Please close or get your existing work merged before picking up a new issue:

• Webhook rate limiting is skipped for event types without an installation field #391 - Webhook rate limiting is skipped for event types without an installation field
• detect.ts uses manual join casts instead of the existing unwrapJoin helper #390 - detect.ts uses manual join casts instead of the existing unwrapJoin helper
• Auth and rate limit boilerplate is copy pasted across 25+ server actions #382 - Auth and rate limit boilerplate is copy pasted across 25+ server actions

Once those are resolved, feel free to re-assign yourself here. Questions? Drop them in GitHub Discussions.

[Ayush-Patel-56]

@diksha78dev feel free to look into it, I'll assign this after reviewing your pending ones, in mean time, if you are done with this then feel free to raise PR.