Audit the Supabase policies Cursor wrote
Cursor tends to produce policies that look right. The failures are subtle rather than absent, which makes them harder to catch by reading and easier to catch by checking.
Rules that check this
- criticalPolicy always evaluates to true
RLS_TAUTOLOGY - highWrite policy without WITH CHECK
MISSING_WITH_CHECK - mediumRLS predicate column is not indexed
UNINDEXED_RLS_PREDICATE
Policies that are always true
A placeholder `USING (true)` written to get something working, then never narrowed. VibeGuard normalises the deparsed expression and recognises the constant-true forms: `true`, `1 = 1`, `NOT false`, matching string literals, and any OR arm that is one of those.
Read policies without matching write policies
The common shape is a correct SELECT policy and an INSERT policy with no WITH CHECK. Reads are locked down, writes are not, and nothing in the app surfaces the difference until someone writes a row they should not be able to.
The performance tax
Generated policies almost always call `auth.uid()` directly rather than wrapping it, and almost never come with an index on the column they filter. Neither is a security bug; together they are the reason the bill grows.
Frequently asked
- Can I re-run this after every prompt?
- That is the intended use. Connect the project and it runs on a schedule; the "Scan now" button forces one immediately.
- Does it read my source code?
- No. It reads the database catalog — what actually shipped — rather than what the source implies.
Check your project in about ten seconds
Paste a URL. No signup, no writes, nothing stored.
Run the free audit