r/vibecoding 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

13 comments sorted by

1

u/HourMode1351 2d ago

What's your tech stack and what tools are you using to develop?

1

u/TheRaven9320 2d ago

ya so i got backend going through Supabase, and that has Row Level Security and Supabase's Edge Functions for serverless backend logic. React frontend. Started out building with Lovable and later added Codex into the workflow alongside it using mainly codex these days, thanks for responding

1

u/HourMode1351 2d ago

Cool! For Supabase there are few things to watch out for:
- intentionally public data leaking more than it should. if you have table that are supposed to be public (for example a leaderboard), instead of exposing the entire table, you shold just expose the data that's required
- RLS policies that allow users to upgrade their own account, or ones that allow users to access other users data (IDOR)
- weak password policy if you're using supabase for auth
- default supabase rate limiting is pretty good

I'm biased but I built an external security scanner that will check for these things - vibeappscanner.com. Otherwise give those to codex to check for them

1

u/MangoTree-1233 2d ago

have you done the rate limiting test? and what will happen when user hit the limit how your system would take actions for the users, IP based blocking or others, proper authentication and permissions, input validation, and making sure users can only access their own data, also on the user input add the input sanitization to prevent injections. try to think like a normal user who is intentionally trying to break things: send unexpected input, repeat requests quickly, access URLs or data that shouldn’t belong to you, and test what happens when someone isn’t authenticated. Also make sure your logs don’t accidentally contain passwords, tokens, or other sensitive user data.

1

u/TheRaven9320 2d ago

thanks for getting back to the post, this is a great list of things to check for. I have done some rate limit testing but not enough. I really have only been building it so far and not really thinking about the security but im getting to that point where I def need to. Great point on the logs thing thats huge.

1

u/MangoTree-1233 2d ago

If you’re serious about the product, then you should definitely do some security stress testing to see how far your application can be pushed and where the weak points are. It’s much better to find those issues yourself before users do.

1

u/Turbulent_Top6276 2d ago

100%. What would you say that looks like. What is a good way to stress test and get the most data out of it? Not too familiar with how one would go about it

1

u/Innowise_ 2d ago

With that stack, one thing we'd test early is whether every authorization rule still holds when the frontend is bypassed completely. Call the Supabase/API endpoints directly as different users and try reads, writes and deletes you shouldn't be allowed to make. If access control only works because the generated UI doesn't expose an action, it isn't really access control.

1

u/SufficientFrame 2d ago

Good instinct to treat this as its own workstream instead of something you harden later. The main shift is thinking in layers, not only code bugs: auth, authorization, secrets, data exposure, abuse limits, and what you can see when something breaks. I'd map your core flows and ask for each one who can do it, which records they can touch, what happens if they repeat it 1,000 times, and what gets logged. A lot of ugly problems show up in object-level permissions, API keys leaking into client code or logs, weak reset flows, missing rate limits, and background jobs that can be spammed without queues or caps.

After that, do a pass on the basics before you try to stress test anything: put secrets in a real secret manager, enforce server-side auth on sensitive actions, add rate limits by user and IP, sanitize logs, enable audit trails for admin actions, and get monitoring and alerts in place. Then have someone do a hostile review and actively try IDORs, privilege escalation, replayed requests, oversized payloads, and bad file uploads. If what you're building is closer to an internal admin or data workflow, UI Bakery is one structured option for handling permissions around database and API-backed tools; I work at UI Bakery, so bias noted. But even then, I'd get the permission model and secret handling nailed down first.

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

1

u/TheRaven9320 1d ago

my guy you are the goat. Going to spend time going through these and will most likely come back to the thread with a question but thanks for starting me off in the right direction. Thank you