Why is Supabase returning a 403 error?

What a 403 actually tells you

A 403 (Forbidden) from Supabase/Lovable Cloud almost always means Row Level Security (RLS) rejected the request. The database understood the query but no policy grants the current user permission to run it.

This is different from a 401 (not authenticated at all) — a 403 usually means the user is recognised, but their role doesn't satisfy any policy on that table for that action.

Common causes

• The table has RLS enabled but no policy for the operation you're attempting (e.g. INSERT policy exists, UPDATE doesn't).
• The policy checks auth.uid() = user_id, but the row's user_id doesn't match the logged-in user.
• You're testing while logged out, and there's no policy for the anon role.
• A policy references a user_roles check that doesn't include the current user's row.

How to fix it

1. Ask Lovable: "This table is returning 403 on insert — show me its RLS policies and check they cover authenticated users inserting their own rows."
2. Confirm the shape of the data you're sending matches what the policy expects (e.g. the row includes the correct user_id).
3. If the table should be publicly readable, ask Lovable to add a SELECT policy scoped to what should really be public — don't disable RLS entirely.

Add an RLS policy so authenticated users can only update rows where user_id matches their own auth.uid()

What usually goes wrong

• Disabling RLS "to make the error go away" — this removes protection entirely and exposes all rows to anyone with the anon key. Fix the policy instead.
• Policies written against a role column on the profiles table instead of a separate user_roles table, which is both a security anti-pattern and a common source of confusing 403s once roles get more complex.

See /questions/what-is-row-level-security-rls and /questions/how-do-i-fix-rls-errors for more detail.