You commented SUPABASE. Here's the full diagram of what's running under a Supabase app, and the five checks to run before you ship. Every claim links to its source, and I'll say where the evidence is thin.
1. The full diagram
[DIAGRAM: final frame of the reel, Nyx adds before publish]
The same diagram in words, in the order the reel walks it. Take the shared shopping list: you tap "add milk" and the tap travels down this list.
Postgres. The database at the bottom. Every Supabase project gets a full Postgres, and Auth, Storage, Realtime and Edge Functions are built on it. Your list is a table and "milk" is a row. Supabase: Database
PostgREST, the auto REST API. A web server that turns your Postgres database into a REST API, so the browser can query it directly. Your tap becomes a database query without server code you wrote. Supabase: REST API · PostgREST docs
Auth and the JWT. Every request carries an API key that says what is calling. When someone is signed in, Auth says who, using a signed token called a JWT. The client library sends it for you. Supabase: API keys · Supabase: Auth
Row Level Security (RLS). A rule attached to a table that Postgres runs on every access. Supabase describes it as adding a WHERE clause to every query. This is the gate between a stranger and your rows. Supabase: Row Level Security
Realtime. Listens to database changes and pushes them to subscribers, which is how "milk" reaches every phone on the list. Supabase: Realtime
Storage. Keeps your files and photos, with access controlled by the same row-level rules. Supabase: Storage
Edge Functions and the secret key. Server-side TypeScript for jobs like Stripe webhooks and sending email. This is where the secret key belongs, because that key skips every rule above. Supabase: Edge Functions · Supabase: API keys
The public key sits in your page's code and anyone can read it. Supabase says so: it "only reaches what Row Level Security allows". That is why check 1 matters most. Supabase: API keys
2. The five checks before you ship
Check 1. RLS is on for every table you expose, and you have read the policies
Supabase's docs say a table in an exposed schema without RLS is readable and writable by any role with a grant on it. Turn RLS on for every such table. Then read the policies for reads and for writes, because a table can be locked for one and open for the other. Look at each table in the Table Editor in your dashboard, and confirm any tables you made through the SQL editor too. Matt Palmer notes that RLS is on by default only for tables made in the Table Editor, which I could not confirm on Supabase's own page today. Supabase: Row Level Security · Palmer's write-up
Check 2. The logged-out test
Open your own app signed out. Try to read and change your own tables. Then open your browser's network tab, find a request your app sends to Supabase, and replay it with the query changed to select=*. If rows come back that a stranger should not see, you have no working rule. Only do this on your own app. Palmer's advice is to test the endpoints as an unauthenticated user, and as one user trying to reach another's private data. Palmer's write-up · Statement on CVE-2025-48757
Check 3. The secret key never leaves the server
Supabase's wording: a secret key "bypasses every Row Level Security policy you have. Never put one in a browser, a shipped application, or source control." Only the publishable key goes in the app. Search your code and your repo for the secret key before you ship. The names changed: "anon" is now the legacy name of the publishable key, and "service_role" is the legacy name of the secret key. Supabase says it is deprecating both by the end of 2026, so tutorials and AI tools may still use the old names. The secret key belongs in server code such as an Edge Function. Supabase: API keys
Check 4. Storage has a policy per bucket
By default Storage does not allow uploads to a bucket without RLS policies. You allow operations by creating policies on the storage.objects table. Write the upload rule and the read rule for each bucket, and check that nothing is open that you did not mean to open. The service key skips these rules entirely, so it must not be shared publicly. Supabase: Storage access control
Check 5. Realtime only broadcasts the tables you mean
For Postgres Changes, a table has to be added to the supabase_realtime publication. In your project's Publications settings, check that only the tables you want to listen to are switched on. Every event is authorised against each subscriber, so 100 subscribers means 100 checks. One catch from the docs: RLS policies are not applied to DELETE statements, because Postgres cannot verify access to a deleted record. Do not put anything sensitive in what a delete event can reveal. Supabase: Postgres Changes
If you used Lovable
Lovable's own docs say each Lovable project connects to one Supabase project, and that before going live you should make sure every table has RLS policies for who can read and write each row. They add: "Missing RLS policies are the most common way app data gets exposed." Their docs also describe a security scan that flags tables without per-record access control and rules that let everyone through. Run it, then still do checks 1 and 2 yourself. Lovable: Supabase integration · Lovable: Security
3. What happened at Moltbook
Security firm Wiz reported that a Supabase database belonging to Moltbook allowed full read and write access to all platform data. The exposure included 1.5 million API authentication tokens, 35,000 email addresses and private messages between agents. Wiz found a Supabase key in the site's client-side JavaScript within minutes. Wiz points out that with RLS configured, that kind of public key is safe to expose. Here, the RLS line of defence was missing, and Wiz traced the issue to a single Supabase configuration setting. Wiz
The fix took more than one round. After the first fix blocked read access to sensitive tables, write access to public tables stayed open, and Wiz says it could modify existing posts. Wiz's timeline runs from the report on 31 January 2026 to "All tables secured" on 1 February, and Wiz says Moltbook secured the database within hours. The founder said publicly that he did not write a single line of the code and that AI did. Wiz does not say which AI tool built it, so I won't guess. Wiz
4. The 2025 Lovable research, and the dispute
Researchers Matt Palmer and Kody Low reported that a scan on 21 March 2025 found 170 of 1,645 Lovable projects, about 10.3%, with inadequate RLS. It covered homepages only. They said exposed data included names, phone numbers, API keys and payment details, and that an attacker could edit a request to select everything from an exposed table. Palmer also says the public key was not the problem. The missing RLS was. Palmer's statement
It became CVE-2025-48757. Read the record carefully: NVD marks it as disputed by Lovable, which says each customer is responsible for protecting the data of their own application. Palmer's own write-up says he worked in developer relations at Replit, a Lovable competitor, at the time. The research is from March 2025, so it tells you nothing about how Lovable apps stand today. I am not saying Lovable was hacked. NVD record · GitHub Advisory
Mike
PS: Want more like this, how the tech you use every day actually works? You're already on the list. Reply and tell me what to break down next.