Avoid development rules in production
Rules such as allowing reads and writes unconditionally are useful only in tightly controlled local work. Production rules should start from denial and grant the smallest access each operation needs.
Authentication is not ownership
A signed-in user should not automatically access every row or document. Policies need to compare the authenticated user ID with the owner or membership recorded on the requested resource.
Check every operation
Read, create, update and delete can require different conditions. Validate the allowed fields on writes and prevent users from changing ownership or privileged roles.
Test from the attacker's position
Use emulators or a staging project to send direct requests without the normal interface. Test unauthenticated access, cross-account access, guessed IDs, bulk queries and attempts to write protected fields.
Protect service-role credentials
Supabase service-role keys and server admin credentials bypass normal client protections. Keep them on trusted servers only and rotate them if they reach a repository or browser bundle.
Frequently asked questions
Does Supabase RLS turn on automatically?
Do not assume it does for every table or workflow. Verify the current state and explicit policies in the project you will deploy.
Are frontend route guards enough?
No. The database or server must enforce access because a user can bypass the interface and call an endpoint directly.