Supabase Security Basics for Portfolio and Client Projects
Practical database-security habits for Supabase projects, including Row Level Security, public reads, admin actions and safe API boundaries.
Treat the database as the real boundary
A browser is not a trusted environment. Anything sent to the client can be inspected, so authorization decisions should be enforced where the data lives.
Supabase makes this practical with PostgreSQL Row Level Security (RLS). Policies should describe who can select, insert, update or delete each kind of row.
Separate public content from admin actions
A portfolio may intentionally expose published projects, services or testimonials. That does not mean every table or every mutation should be public.
A useful pattern is public read access only for published content, while create/update/delete operations require an authenticated admin identity and a policy that checks that identity.
Keep secrets server-side
Public browser configuration is not the same thing as a private service credential. Never place privileged database keys or secrets in client components or public environment variables.
For sensitive operations, move the action behind a protected server boundary and validate the user before touching privileged data.