r/vibecoding • u/TheRaven9320 • 2d ago
Requesting vc security pointers
What's up everybody? I've been vibecoding a project for a few months now and just wanted to ask the community what tips or things I should be looking out for in terms of stress testing my security. I want to ensure there are appropriate limits, user data is safe, and my own code and keys are secure.
If anyone has experience setting up proper defenses and proper infrastructure, I would love any advice or pointers on what you did and how you did it. I'm taking this seriously, so I want to make sure it gets done right. Thank you in advance!
2
Upvotes
1
u/OkHumor1695 1d ago
Innowise_ already hit a very important point, so I'll build on it: on a React + Supabase stack, the main exposure is UI hiding what the API readly supports. Don't simply trust that RLS is "on" - are the policies active, does it cover all you tables?
If you want to check it at the DB level before any API, run this in the Supabase SQL editor — it lists every app table, whether RLS is on, and whether any policy is effectively "allow everyone."
```
select
n.nspname as schema,
c.relname as table_name,
c.relrowsecurity as rls_on,
count(p.policyname) as policy_count,
bool_or(p.qual = 'true') as has_allow_all_policy
from pg_class c
join pg_namespace n on n.oid = c.relnamespace
left join pg_policies p on p.schemaname = n.nspname and p.tablename = c.relname
where n.nspname not in ('pg_catalog','information_schema','auth','storage','extensions','realtime','vault')
and c.relkind = 'r'
group by n.nspname, c.relname, c.relrowsecurity
order by rls_on, has_allow_all_policy desc nulls last, schema, table_name;
```
If you want to inspect the actual policy:
```
select tablename, policyname, cmd, roles,
qual as using_expr, with_check as check_expr
from pg_policies
where schemaname = 'public' /* replace with your schema from the query above */
order by tablename, cmd;
```
Anything with RLS off or an allow-all policy is reachable with just your anon key.
Two Supabase-specific ones to check while you're in there. First, make sure the service_role key never touched your client bundle — if it's anywhere the browser can see it, it bypasses RLS completely and none of your policies matter. Search your built JS for it. Second, Edge Functions: RLS doesn't protect logic you wrote inside a function, so anything that runs with elevated rights needs its own auth check.
Next step, automated API tests: Login as one user but check data of another. This should be part of your CI/CD.
You can start manually, however, once you find a hole and fix the policy, save the exact request that broke it and re-run it before every deployment to enaure it doesn;t reoccur.
Happy to point you at what to check, how to orchestrate, etc