Row-level security is your API, so write it first

A Supabase anon key is public. It ships in the browser bundle, it appears in network traces, and treating it as a secret is a category error. The only thing standing between that key and your data is row-level security.

So write the policies first, before the first query. For a marketing site the shape is simple: published rows are readable by anyone, nothing else is, and the only write anyone can perform is inserting a contact enquiry.

That last policy is the interesting one. An insert-only policy on a leads table means a visitor can submit the form but cannot read back what anyone else submitted. Without it, the same key that powers your contact form hands over every lead you have ever received.

Enable RLS on every table in the same migration that creates it. A table created without RLS and given a policy later has a window where it was open, and that window tends to be the one that gets indexed.

Test the policies the way an attacker would: open a client with only the anon key and try to read the leads table. If it returns rows, the policy is wrong, and no amount of validation in your application code will save you.