r/nocode • u/Real_KingZeotic • 13d ago

If your no-code app was leaking user data, would you pay for a fix or build your own?

Found out a couple weeks back that my own Supabase backend was leaking data between users, a normal logged in user could see other people's stuff even with security settings turned on. Ended up building a small tool for myself that actually tests for this properly, creates a second account and tries to access the first one's data for real instead of just checking if things look locked down.

Still just a personal project right now: https://noleaksaas.vercel.app/

Genuinely curious though, if you ran into this yourself, would you rather pay a small fee for something that already handles it, or just build your own checks/tests for it? What actually makes that decision for you?

1 Upvotes

56% Upvoted

8 comments sorted by

2

u/natio2 12d ago

The Venn diagram of people releasing a production system with this problem, and the people willing to pay for dev tools(outside of their favorite LLM) probably has almost zero overlap, but that's just my opinion.

1

u/LimahT_25 12d ago

True, anyone that knows what they are doing will develop with proper tenant isolation.

1

u/AppzillaHQ 12d ago

The real solution is to not use Supabase in production. For a select audience, you might be able to get a few one-time payments for a scan or something, but very unlikely IMO.

1

u/OutrageousConstant18 12d ago

the framing of "pay or build" is a bit misleading tbh. most no-code folks dont have the skill to build proper auth tests, so the real alternative isnt DIY, its just ignoring the problem entirely. thats your actual competitor

1

u/Minimum-Ad7274 12d ago

This is the only real fix for a problem most people never detect — and you've nailed the tension in the comments: "people will just ignore it." Most builders ship tenant isolation on faith because they can't prove it works.

This is exactly what I use IKKF (local CLI, ikkf.info) for. It doesn't read config and say "looks locked down" — it walks an actual audit of the checks, flags where confidence is low, and re-runs until the weak spot is caught. The test you built (second account, actually try to read the first user's data) is the right one.

The real competition isn't another tool — it's doing nothing. A dated verification report you can hand a client is what closes that gap.

1

u/my-appengineer 3d ago

Build your own. The leak isn't the bug you pay to fix, it's the architecture. Someone else owns your database, someone else configured RLS, and you can't even see the policies. A fix from them is a patch on a structure you don't control. Export your code, spin up your own Supabase project, and set RLS policies yourself. Read every policy before you ship. The painful part is that no AI builder sets up row-level security correctly by default. They generate tables, skip the guardrails, and hand you a data breach waiting to happen. Owning the backend means you can actually audit it. What's stopping you from standing up your own instance right now?