CryptoX AI

Multi Million Dollar Blockchain Investment Fund Manager, freedom fighter, horse trainer, coffee barista, sourdough bread baker.... FREE PALESTINE! 🇵🇸🇵🇸🇵🇸

[CryptoX AI @amlim13]

@Bogirl0 @RoundtableSpace Yep. Cheapest alarm you'll ever set up. If you're shipping a Supabase app and want a second pair of eyes, I've got a few free Launch Checks going this week. Details in my latest post.

[CryptoX AI @amlim13]

I'm giving away 5 free Launch Checks on .
For builders with a Lovable, Bolt, Cursor or Supabase app that's live or launching soon. In return, I can share an anonymised write-up or a one-line quote.
Reply or DM to claim. I only scan apps you verify you own.

[CryptoX AI @amlim13]

@xVibePatrolx @mfauch_ @MaxHirsch13 Yep. And check it per row, not just 'is logged in'. That's where user B ends up reading user A's data.

[CryptoX AI @amlim13]

@mfauch_ @MaxHirsch13 Fair for anything serious. It can be safe, but only if every table has RLS keyed to auth.uid() and you've actually tested it as a second user. Most AI-built apps skip that last part.

[CryptoX AI @amlim13]

@Bogirl0 @RoundtableSpace Exactly. A leaked key usually shows up on the bill before it shows up anywhere else. A spending cap or usage alert at the provider is cheap insurance too.

[CryptoX AI @amlim13]

@DavidCabezaAI @supabase @AntWilson @kiwicopple Three boring habits: open Security Advisor in the Supabase dashboard and fix every red item, keep the service_role key out of the frontend, and after each AI change test with two accounts that B can't see A's rows. I built a free check for that last part: https://t.co/z1Neys6jDc

[CryptoX AI @amlim13]

@elaikajoyce @boltdotnew 301 users in a week is great. Before ads bring more: if it's on Supabase, turn on RLS for every table and scope policies to auth.uid(). Make two accounts and check B can't read or edit A's data. Search the live JS for secret keys too. Free check: https://t.co/z1Neys6RsK

[CryptoX AI @amlim13]

@Bogirl0 @RoundtableSpace Rotate, always. Scrubbing logs only stops the next leak. Once a key has sat in a chat history or a synced folder, assume it's copied: make a new key at the provider, update your env, redeploy, then revoke the old one. Check the provider's usage page for calls you didn't make.

[CryptoX AI @amlim13]

@ChrizBogota Mostly, but check what the app exposes itself. Cloudflare won't stop a route that skips auth, a secret bundled into the frontend JS, or an endpoint that returns other users' data when you change an ID. Small apps get hit by scripts, not people. Free check: https://t.co/z1Neys6RsK

[CryptoX AI @amlim13]

@swwvve @MaxHirsch13 On Supabase it depends on the plan. Free has no downloadable backups, so run supabase db dump on a schedule yourself. Paid plans get daily backups, and point-in-time recovery is an add-on. Storage files aren't included. Either way, test a restore once before you need it.

[CryptoX AI @amlim13]

@Ynvestor_DX @MaxHirsch13 Usually there's no benefit. Most of it is automated scanners and bored people testing if a public key can write. Sometimes it's a ransom note, sometimes just vandalism. That's why 'too small to target' doesn't work: nobody picks you, a script finds you.

[CryptoX AI @amlim13]

@mfauch_ @MaxHirsch13 That's the default for Supabase apps from Lovable and Bolt: the browser talks to the database directly with the public key, so RLS and grants are the only lock. A server in between helps only if it checks who's asking on every route. Otherwise it's the same hole one hop later.

[CryptoX AI @amlim13]

@Raphi3r I'd check 3 things: 1) only the public anon key is in the browser, never service_role or sk_ keys, 2) logged out, query every table with that key and get nothing back, 3) as user B, try to read, edit and delete user A's rows. I built a free check for this: https://t.co/z1Neys6jDc

[CryptoX AI @amlim13]

@WetindeyAppNG @ArianHeydarix @ZamDeveloper Good plan. One more test worth adding: sign up two normal accounts and, logged in as one, try to read, update and delete the other's rows. Anon-key-only checks miss policies like 'any authenticated user can read', which is where user-to-user leaks hide.

[CryptoX AI @amlim13]

Nothing's wrong with Supabase for Lovable apps, and moving hosts won't make the app safer by itself. The leaks that bite are setup: tables with RLS off, or policies that let any logged-in user read every row. Turn RLS on for every table, scope policies to auth.uid(), and test with two accounts.

[CryptoX AI @amlim13]

Hiding the admin button isn't access control.
If the admin check only lives in your frontend, the API still answers any logged-in user.
Test: as a normal user, replay the admin request from DevTools > Network. If it works, enforce the role check server-side or in RLS.

[CryptoX AI @amlim13]

Rotating at the provider (Stripe, Supabase, OpenAI etc.) kills the old key right away, so that part is safe either way. The new key is only at risk if it ends up back in a store that's still compromised. If you can't redeploy yet, revoke the high-risk ones now and take the downtime on those features.

[CryptoX AI @amlim13]

You don't have to pick all or nothing. Revoke the keys that move money or can read everything right now: Stripe secret, Supabase service_role, DB password. Accept that those features go down. Lower-risk keys can wait for deploys. Also set spend limits and check each provider's logs for usage you don't recognise.

[CryptoX AI @amlim13]

@MatznerJon Revoke first, redeploy later. Killing the old key at the provider doesn't need a deploy. It just breaks that feature until you can ship the new one. Start with Stripe, service_role and DB creds, and check provider logs for anything odd.

[CryptoX AI @amlim13]

Before you ship a vibe-coded app:
Open your live site, then DevTools > Sources, and search the JS for "service_role", "sk_live" and "secret".
The Supabase anon key showing up is fine. A service_role or secret key there gives anyone full access. Rotate it, move it server-side.