Vibe coders: how do you handle security for apps that touch bank/tax data?
I've been building a SaaS with Lovable + Supabase that handles pretty sensitive stuff — bank data via Open Banking, tax-related info. It's still in beta with very few users, but I want to get security right before opening it up more.
I know the basics (HTTPS, not exposing API keys in the frontend), but I'm not confident I've covered what actually matters for something handling financial/tax data.
For anyone who's dealt with this:
What would you consider the absolute minimum before letting real users connect their bank accounts to something you built solo?
Specifically wondering about:
How strict should Row Level Security be on Supabase for multi-tenant data (each user should only ever see their own records)
Whether a paid security audit is worth it at pre-launch/beta stage, or if that's overkill until there's real traction
How people handle storing tokens from services like Open Banking connectors — encrypted at rest, rotated, etc.
Genuinely trying to avoid finding out the hard way. Any war stories or checklists appreciated. 🙏
Replies
RLS on every table, no exceptions, and every policy keyed on auth.uid(). Never on a user id your frontend sends. Your anon key ships in the browser by design, so a table without RLS is readable by anyone who opens devtools. That's how a batch of Lovable apps leaked last year.
My own app isn't on Supabase, but the rule is the same. Every server endpoint takes the user from the session and ignores any user id in the request. Feels paranoid until you remember every endpoint is public, whatever the UI shows.
Tokens: keep the Open Banking refresh token server-side only (an edge function, or Supabase Vault), never send it back to the client, never log it.
For something handling bank/tax data, I would keep the pre-launch checklist pretty simple.
Test tenant isolation. Actually try accessing another user's records, including through APIs.
Keep banking tokens server-side. Never expose or log them.
Treat every API endpoint as publicly accessible. Verify authorization independently of the UI.
Test backups, access revocation, and audit logging. Don't just assume they work - actually restore them every now and then.
Get an experienced pair of eyes on the architecture before opening up.
I would not spend thousands on a formal audit just yet. A focused security review should uncover the biggest risks first.
One question: Have you actually tried breaking your own tenant isolation, or only verified that the RLS policies look correct?