DEV Community: Ayondip Jana

Supabase RLS checklist for Lovable and Bolt apps: what we found in 38 codebases

Ayondip Jana — Sun, 01 Nov 2026 06:24:19 +0000

Picture an invoicing app called Billtrack, built in a weekend with Lovable. It has a Supabase database with one table, invoices, and two users, Alice and Bob. Alice should see her two invoices. Bob should see his one.

The app works. Alice logs in and sees her invoices. Then anyone who opens the browser's network tab can copy the Supabase URL and the anon key out of a request, run one curl, and get all three invoices, including Bob's.

That is the bug behind CVE-2025-48757. A security researcher scanned 1,645 apps from Lovable's public showcase and found 170 with Supabase tables readable using only the public key. The exposed data included emails, addresses and in some cases API keys. The NVD entry notes that Lovable disputes the CVE, on the grounds that each customer is responsible for protecting their own app's data. Either way, the fix is in the app's database.

It wasn't a one-off. In October 2025, the security firm Escape.tech scanned more than 5,600 public apps built with Lovable, Base44, Create.xyz, Vibe Studio and Bolt.new. It found more than 2,000 vulnerabilities, more than 400 exposed secrets and 175 cases of exposed personal data, including medical records and bank account numbers. It named missing or misconfigured RLS and Supabase service role keys sitting in frontend bundles among the main causes.

We wanted to know whether that is still true a year later, so we looked at the code ourselves.

What we found in 38 public Lovable codebases

In October 2026 we searched GitHub for public repositories generated by Lovable, using the lovable-tagger package it adds to every project. We found 933. Of those, 218 include their Supabase migrations, the SQL files that create the database tables and their security rules. We picked 40 at random, and 38 of them defined tables in the public schema. We replayed each repository's migrations in order and recorded the final state of every table, then checked the serious findings by hand.

We only read code. We didn't connect to any live app or database, and we don't name any repository here.

Finding	Repositories	Share
At least one table with RLS turned off	2 of 38	5%
Policies that let anyone, signed in or not, update or delete every row	6 of 38	16%
Policies that let any signed-in user update or delete every row	4 of 38	11%
At least one of the three above	10 of 38	26%
A view that doesn't apply the table's RLS (`security_invoker` not set)	6 of 38	16%

The first row surprised us. Only 2 of the 826 tables we found had RLS off. Missing RLS, the problem behind CVE-2025-48757, has become rare in Lovable's generated code. The risk has moved into the policies themselves, which a check for "is RLS on" does not catch.

Two patterns stood out.

The first is a temporary policy that never left. One billing app created FOR ALL USING (true) policies on its customers, invoices and payments tables, with a comment saying they allowed all operations "for now" and could be restricted later. Later migrations added proper per-user policies next to them but never dropped the open ones. Because Postgres combines policies with OR, the open policy still wins, so anyone with the public key could read and change every invoice.

The second is a policy named for one role that applies to all of them. Another app had a policy called "Service can manage all jobs" with FOR ALL USING (true) and no TO service_role clause. Without that clause a policy applies to every role, so the background-job table was writable by anonymous visitors.

Some of these repositories are prototypes, and a live database can differ from its migrations if someone changed it by hand. So these numbers describe what the code would create, not what is running. They are still the code a founder would deploy.

The rest of this post shows exactly what each kind of mistake exposes, and ends with the checklist we use.

Why AI-built apps hit this so often

A traditional web app has a backend server between the browser and the database. The server decides who can see what.

Apps generated by Lovable, Bolt and similar tools usually skip that server. The browser talks to Supabase directly, through an auto-generated REST API, and it sends a key that is meant to be public: the anon key. Supabase's own docs describe what makes that safe. Postgres row level security (RLS) runs on every request and filters rows per user. The docs put it plainly: enable RLS on every table in an exposed schema.

So the anon key is not the secret. The RLS policies are the security model. If a table has RLS off, the public key opens all of it. RLS is not switched on for you when a table is created with SQL. Supabase's docs point to event triggers if you want that to happen automatically, and they note that on some projects a new table in public starts with every privilege already granted to all three API roles.

What we tested

We rebuilt Billtrack's database in a lab: PostgreSQL 16, PostgREST 12.2.3 (the API layer Supabase uses), the same three roles Supabase uses (anon, authenticated, service_role), and an auth.uid() function that reads the user ID from the request's JWT, as Supabase does. Then we called the API as an anonymous visitor, as Alice, and as the service role, after each change.

State of the `invoices` table	Anonymous visitor	Alice
RLS off	All 3 invoices	All 3 invoices
RLS on, no policies	Nothing	Nothing
RLS on, policy scoped to `auth.uid()`	Nothing	Her 2 invoices
Same, plus an extra `using (true)` policy	All 3 invoices	All 3 invoices
A view over the table, default settings	All 3 invoices	All 3 invoices

The rest of this post goes through each row.

Check 1: run the anon-key test on your own app

This is the test a stranger would run. Use it only on an app you own.

curl 'https://YOUR-PROJECT.supabase.co/rest/v1/invoices?select=*' \
  -H "apikey: YOUR_ANON_KEY" \
  -H "Authorization: Bearer YOUR_ANON_KEY"

Both values are already in your frontend code. If this returns rows that belong to real users, the table is open to the internet.

Reads are only half of it. With RLS off, our anonymous test also inserted a new invoice and changed the amount on Bob's invoice from 4,300 to 1. Both requests succeeded. An open table is writable, not just readable.

Check 2: turn RLS on for every table in `public`

This query lists every table and whether RLS is on:

select tablename, rowsecurity
from pg_tables
where schemaname = 'public';

Any false is a table the anon key can reach. Turning RLS on is one line:

alter table invoices enable row level security;

Expect the app to "break" right after. With RLS on and no policies, Postgres denies everything, so Alice also saw an empty list in our test. That's correct behavior. Access now has to be granted on purpose.

Check 3: write policies that name the user

The policy that fixed Billtrack lets a signed-in user read only their own rows:

create policy "read own invoices" on invoices
  for select to authenticated
  using ((select auth.uid()) = user_id);

After this, Alice got her two invoices and the anonymous visitor got nothing. Two details matter:

to authenticated keeps anonymous visitors out of the policy entirely. Without a role, a policy applies to everyone.
Wrapping auth.uid() in (select ...) is Supabase's own performance advice. It lets Postgres evaluate the function once per query instead of once per row.

Writes need their own policies. With RLS on and only a read policy, Alice's insert was rejected with new row violates row-level security policy. The insert policy uses with check, which tests the new row:

create policy "insert own invoices" on invoices
  for insert to authenticated
  with check ((select auth.uid()) = user_id);

Check 4: look for policies that say `true`

When an AI tool hits a permission error, a common "fix" is a policy that allows everything. We added one next to the correct policy:

create policy "anyone" on invoices for select using (true);

The anonymous visitor got all three invoices again. Postgres policies are permissive by default, so a row is visible if any policy allows it. One loose policy cancels every careful one.

Writes have the same trap. With an insert policy of with check (true), Alice created an invoice with Bob's user_id, and it was accepted. With the auth.uid() version, the same request was rejected.

This query shows every policy and its condition, so true stands out:

select tablename, policyname, cmd, roles, qual, with_check
from pg_policies
where schemaname = 'public';

Check 5: check every view

Views are easy to miss. We created a simple view over invoices and granted it to the API roles, with RLS on and correct policies on the table. The anonymous visitor read all three invoices through the view.

Supabase's docs explain why: views bypass RLS by default because they are usually created by the postgres user. On Postgres 15 and later, one setting makes a view obey the table's policies:

alter view invoice_totals set (security_invoker = true);

After that, the anonymous visitor got nothing through the view and Alice got her two rows. On older Postgres versions, revoke access to the view from anon and authenticated, or move it to a schema the API doesn't expose.

Check 6: keep the service role key off the browser

Supabase's secret key maps to the service_role Postgres role, which has the bypassrls attribute. In our lab, the service role read all three invoices even with every policy in place. That's by design, for trusted server code.

It becomes a leak when the key ends up in frontend code. Environment variables with a NEXT_PUBLIC_ prefix in Next.js, or VITE_ in Vite, are built into the JavaScript the browser downloads. Search your codebase and your built files for the secret key. If it appears anywhere in client code, rotate it in the Supabase dashboard, then move the code that needs it into a server function.

Moltbook, an AI-agent social network, shows what one exposed key does. In February 2026, researchers at Wiz reported that a Supabase key in Moltbook's client-side JavaScript gave unauthenticated read and write access to its whole production database, because the tables had no RLS policies. Wiz reported 1.5 million API authentication tokens and about 35,000 email addresses in the exposed data. Once it was reported, the fix was reportedly two SQL statements.

What surprised us

RLS fails silently. When a policy blocked a read or an update, the API returned an empty list with HTTP 200, not an error. An anonymous update to Bob's invoice came back as [], status 200, and nothing changed. For a founder testing their own app, "it returns nothing" looks like a bug to fix, and the quickest fix is the using (true) policy from Check 4.
The view leak. We expected the view to follow the table's policies. It didn't, until security_invoker was set.
Our own test setup lied to us once. We ran a drop-and-create of two policies as one psql command. The create failed because the policy already existed, so Postgres rolled back the drop too, and the next test passed for the wrong reason. We only caught it because the inserted rows didn't match what we expected. Re-run security tests from a clean state, and check the data, not just the status code.

The checklist

Before an AI-built Supabase app goes live:

Run the anon-key curl against every table. Real user data in the response means the table is open.
Run the pg_tables query. Every table in public should show rowsecurity = true.
Give every table a policy per operation (select, insert, update, delete) that names a role and checks auth.uid().
Run the pg_policies query and remove any policy whose condition is true, unless the data is meant to be public.
Set security_invoker = true on every view, or revoke API access to it.
Search client code and build output for the secret key. Rotate it if found.

If you'd rather have someone run these checks on your app, talk to us. We do this as a fixed-scope audit for apps built with Lovable, Bolt and similar tools.

FAQ

Is the Supabase anon key a secret?

No. It's designed to be public and is shipped in every frontend that uses Supabase from the browser. Security comes from row level security policies, not from hiding the key.

What is CVE-2025-48757?

A vulnerability record for Lovable-generated apps whose Supabase tables could be read or written with only the public anon key, because row level security was missing or incomplete. The researcher found 170 affected apps out of 1,645 scanned. Lovable disputes the CVE, saying each customer is responsible for their own app's data.

Why does my app show no data after I enable RLS?

With RLS on and no policies, Postgres denies every row. Add a policy for each operation the app needs, scoped to auth.uid(). Don't fix it with using (true), which opens the table again.

Do Supabase views respect row level security?

Not by default, because views are usually created by the postgres user and run with its rights. On Postgres 15 and later, set security_invoker = true on the view.

How common are RLS mistakes in Lovable apps?

In our October 2026 review of 38 randomly chosen public Lovable codebases, only 2 of 826 tables had RLS turned off, but 10 of the 38 repositories (26%) had policies letting anyone, or any signed-in user, update or delete every row in at least one table.

Is it safe to use the service role key in the browser?

No. The service role bypasses row level security completely. Keep it in server-side code only.

Originally published on inople.com.

Unlock Chrome's Superpowers: Understanding and Building Your First Extension

Ayondip Jana — Fri, 04 Apr 2025 05:45:25 +0000

Google Chrome is more than just a window to the web; it's a powerful platform. And one of its most potent features? Chrome Extensions.

You've probably used them – maybe an ad blocker, a password manager, or a grammar checker. These tiny programs live inside your browser, enhancing your workflow, customizing your experience, and adding functionalities Chrome doesn't have out-of-the-box.

But have you ever wondered how they work? Or even thought about building one yourself? It might seem daunting, but creating a basic Chrome Extension is surprisingly accessible, even if you're relatively new to web development.

This post will demystify Chrome Extensions: we'll explore what they are, why they're useful, and then walk you through building your very own simple extension from scratch!

What Exactly Are Chrome Extensions?

Think of Chrome Extensions as mini-applications that run within the Chrome browser. They are built using standard web technologies:

HTML: For structure (like the popup window).
CSS: For styling (making things look good).
JavaScript: For logic and interaction (making things do stuff).

Extensions can interact with web pages you visit, modify the browser's interface, communicate with web servers, and access various browser APIs (like bookmarks, tabs, history, etc.).

Why Use (or Build) Them?

Productivity: Automate repetitive tasks, integrate different services, manage tabs efficiently.
Customization: Change the appearance of websites, add custom keyboard shortcuts, tailor your browsing environment.
Information: Quickly access specific data, get definitions, check prices.
Utility: Block ads, manage passwords, take notes, check grammar.
Fun & Learning: Building extensions is a fantastic way to learn web technologies and understand how browsers work under the hood.

Let's Build! Your First Chrome Extension (A Simple Popup)

Ready to dive in? We'll create a very basic extension that shows a simple "Hello, World!" message when you click its icon in the Chrome toolbar.

Prerequisites:

Google Chrome: Obviously!
A Text Editor: Anything from Notepad/TextEdit to VS Code, Sublime Text, or Atom will work.
Basic understanding of HTML (Optional but helpful): We'll keep it super simple.

Step 1: Create Your Project Folder

First, create a new folder somewhere on your computer. Let's call it hello-extension. All the files for our extension will live inside this folder.

Step 2: The Manifest File (manifest.json)

Every Chrome Extension must have a manifest.json file. This file is the blueprint – it tells Chrome essential information about your extension, like its name, version, and what it does.

Inside your hello-extension folder, create a new file named manifest.json and paste the following code into it:

{
  "manifest_version": 3,
  "name": "Hello World Extension",
  "version": "1.0",
  "description": "A simple extension that shows a popup.",
  "icons": {
    "16": "icon16.png",
    "48": "icon48.png",
    "128": "icon128.png"
  },
  "action": {
    "default_popup": "popup.html",
    "default_icon": {
      "16": "icon16.png",
      "48": "icon48.png"
    }
  }
}

Let's break this down:

manifest_version: Specifies the manifest file format version. Version 3 is the current standard.
name: The name of your extension, shown in the Extensions page and potentially the Chrome Web Store.
version: The version number of your extension.
description: A short explanation of what your extension does.
icons: Specifies icons for your extension in different sizes. Chrome uses these in various places (Extensions page, toolbar, etc.). We'll create placeholder icons soon.
action: Defines what happens when the user clicks the extension's icon in the toolbar.
- default_popup: Tells Chrome to open popup.html when the icon is clicked.
- default_icon: Specifies the icon to display in the toolbar.

Step 3: Create the Popup HTML (popup.html)

Now, we need the actual HTML file that will be shown as the popup.

Inside your hello-extension folder, create a new file named popup.html and paste this basic HTML code:

<!DOCTYPE html>
<html>
<head>
  <title>Hello!</title>
  <style>
    body {
      width: 150px; /* Give the popup a defined width */
      height: 100px; /* Give the popup a defined height */
      text-align: center;
      font-family: sans-serif;
    }
  </style>
</head>
<body>
  <h1>Hello,</h1>
  <p>Extension!</p>
</body>
</html>

This is just a simple HTML page with a heading and a paragraph. We've added a little inline CSS (<style>) to give the popup a fixed size and center the text.

Step 4: Create Placeholder Icons

The manifest file refers to icon16.png, icon48.png, and icon128.png. You need to create these files.

For this tutorial, you don't need fancy icons. You can:

Find any small PNG image online (respecting licenses!).
Use a simple graphics editor (like Paint, GIMP, Photoshop) to create three squares of solid color.
Important: Save them as icon16.png (16x16 pixels), icon48.png (48x48 pixels), and icon128.png (128x128 pixels) directly inside your hello-extension folder. Make sure the names match exactly what's in the manifest.json.

Your hello-extension folder should now contain:

manifest.json
popup.html
icon16.png
icon48.png
icon128.png

Step 5: Load Your Extension in Chrome

Now for the exciting part – loading your creation into Chrome!

Open Google Chrome.
Type chrome://extensions into your address bar and press Enter.
In the top-right corner of the Extensions page, toggle the "Developer mode" switch ON.
New buttons will appear. Click the "Load unpacked" button.
A file browser window will open. Navigate to and select your hello-extension folder (the whole folder, not just the files inside it). Click "Select Folder" or "Open".
If everything is correct, you should see your "Hello World Extension" card appear on the page! You'll also see its icon (the 48x48 one) appear in your Chrome toolbar (you might need to click the puzzle piece icon to see it and pin it).

Step 6: Test It!

Click the icon for your "Hello World Extension" in the Chrome toolbar.

Voila! The popup.html file should appear, displaying your "Hello, Extension!" message.

Congratulations! You've just built and loaded your very first Chrome Extension!

Taking It Further

This was just scratching the surface. Chrome Extensions can do much more complex things:

Content Scripts: JavaScript files that run in the context of web pages. They can read or modify the DOM (the structure of the page). Think about how grammar checkers highlight text on a page.
Background Scripts (Service Workers in Manifest V3): Run in the background, listening for browser events (like a tab updating, a bookmark being created, or the extension icon being clicked if there's no popup).
Options Pages: Allow users to customize your extension's settings.
Using Chrome APIs: Interact with browser features like tabs, windows, bookmarks, storage, notifications, and much more.

Where to Learn More:

Official Chrome Developer Documentation: https://developer.chrome.com/docs/extensions/ - This is your primary resource. Start with the "Getting Started" and "Overview" sections.
Explore Sample Extensions: Google provides many examples to learn from.
Experiment! Try adding some CSS to style your popup differently, or add some JavaScript to popup.html to make it interactive.

Conclusion

Chrome Extensions are a powerful way to tailor your browsing experience and boost your productivity. While they can become complex, getting started with a simple popup is straightforward using basic web technologies. Hopefully, this guide has demystified the process and inspired you to explore the possibilities.

What extension ideas do you have? Share them in the comments below! Happy coding!