supabase-security/ Oct 30

Reaches existing projects on Oct 30, 2026

After Oct 30, new Supabase tables ship locked. We get you ready in 48 hours.

From Oct 30, new tables in public get no automatic access for the API roles. Existing tables keep theirs, but the next table you create, and every migration replayed on a fresh project, returns 42501. The bulk grant in Supabase’s own rollback fixes that by reopening anon. We send a pull request with per-table grants, verified against your row level security, plus a CI check.

Free check: paste your GitHub link, see the result in seconds. Fix Pack: one project, pull request within 48 hours of access, or a full refund.

Apr 28Announced
May 30New projects
Oct 30Every existing project

34 days until it reaches existing projects. Supabase is emailing project owners now.

Sept 25: UpGuard found about 16,000 Supabase databases with tables anyone could read, many holding personal data. TechCrunch

One migration, four outcomes. Tap each step.

Same migration, merged Nov 3

-- 20261103_invoices.sql
create table public.invoices (
  id      bigint primary key,
  user_id uuid not null,
  total   numeric not null
);
alter table public.invoices
  enable row level security;
create policy "own invoices"
  on public.invoices
  for select to authenticated
  using (user_id = auth.uid());

What your app gets

GET /rest/v1/invoices
signed-in user

403 Forbidden
{
  "code": "42501",
  "message": "permission denied
    for table invoices"
}

Breaks, for new tables. Existing tables keep their grants, so nothing fails on Oct 30 itself. The next table you ship fails, and so does every migration you replay on a new project.

Behavior as described in Supabase’s changelog of Apr 28, 2026. Table names are examples.

Free, no credentials

Is your Supabase app ready for Oct 30? Check it in a minute.

Paste your GitHub repo. We read the SQL in supabase/migrations, show you red, amber or green right here, and email you the full report: what it means for your business in plain English, then the technical detail and the SQL to fix it.

Built it with Lovable, Bolt or Cursor? Paste your project’s GitHub link. On Lovable: open the project, click GitHub (top right), connect it, then copy the repo link. No GitHub at all? Tick “I don’t have a repo” and we’ll email you how to check it from the Supabase dashboard.
  • Tables anyone with your public key can read or change
  • Tables that will fail with 42501 after Oct 30, or on a fresh deploy today
  • The “lazy fix” bulk grant, and database functions anyone can call

We read your code only; nothing touches your database. Public repos. Private one? Run npx supabase-security migrations locally.

Monorepo? Link the folder, e.g. …/tree/main/apps/web

You are

Free. We never ask for keys or passwords.

Pick how far you want to go.

Supabase’s Security Advisor already lists what’s affected, for free. You’re paying for the fix: written, delivered as a pull request you review and merge, verified with real API calls, and guarded in CI. We don’t touch production.

Oct 30 Fix Pack

Keep shipping tables after Oct 30 without opening anything.

$490one-time

1 project, delivered in 48 hours

  • Pull request with least-privilege grants for every table, view, sequence and RPC function your app reaches through the API
  • Row level security checked on every table those grants expose
  • Verified before you merge: your migrations replayed on a clean database, then called as anon and as a signed-in user
  • CI check that fails the build when a migration adds a table without grants
Get the Fix Pack, $490

Order by Tue, Oct 27 to have it merged before Oct 30.

Recommended

Hardening + Proof Report

For apps whose customers ask how their data is protected.

$1,490one-time

1 project, delivered in 5 business days

  • Everything in the Fix Pack
  • Audit of RLS policies, storage buckets and database functions
  • Live test with your anon key against your own project, with your written OK: we show exactly what an outsider can read
  • Each fix as its own pull request
  • A report you can attach to customer security questionnaires (see a real one)
Get Hardening, $1,490

Order by Thu, Oct 22 to have it before Oct 30.

Agency Fleet

For studios and agencies running Supabase apps for clients.

$4,900one-time

Up to 10 client projects, 10 business days

  • The Fix Pack on up to 10 client projects
  • White-label reports under your agency’s name
  • CI check installed in every repo
  • A re-test after Oct 30, then 90 days of weekly monitoring on every project
Get Agency Fleet, $4,900

Order by Thu, Oct 15 to have all 10 before Oct 30.

Delivery times start when we have access to the repo. More than 10 projects, or something else? Email for a quote.

Payments are processed by Stripe under our parent company, Rotate Pilot.

If a table we covered breaks after Oct 30, we fix it free. If we’re late, you get every dollar back.

Covered tables stay reachable

Every table in our pull request is listed by name. If one of them can’t be reached through the Data API after Oct 30, we fix it at no charge.

On time, or refunded

If the deliverable isn’t in your hands within the time on your plan, counted from when you give us access, we refund 100% of what you paid.

The change locks new tables. It leaves three doors open.

  1. Old grants stay

    Existing tables keep every grant they have today, including tables that were never meant to be public. Changelog

  2. The official rollback reopens anon

    Supabase’s rollback grants select, insert, update and delete on every table in public to anon. Safe only where every table has RLS and correct policies.

  3. RPC functions stay callable

    Postgres lets PUBLIC execute functions, and anon inherits it. The revoke in Supabase’s docs doesn’t remove it. Issue #49338

Our pull request closes all three for the tables and functions your app uses, and the CI check keeps them closed.

The check we run first. Try it on your repo.

Our migration linter reads your supabase/migrations folder offline. No credentials, no network calls. It shows what’s missing; the pull request is what fixes it.

npx supabase-security migrations
  • Flags tables created without grants for the API roles
  • Flags blanket grants to anon that reopen tables without RLS
  • Runs in GitHub Actions on every pull request

Open source, MIT. Source on GitHub.

Example output
$ npx supabase-security migrations
Reading supabase/migrations (42 files)

error 20261103_invoices.sql:1
  public.invoices has no grants for
  anon, authenticated or service_role.
  After Oct 30 the API returns 42501.

error 20260911_hotfix.sql:3
  grant all on all tables in schema
  public to anon
  Reopens 4 tables with RLS disabled.

warn  20260802_stats.sql:14
  function public.get_stats() is
  security definer, and anon can call
  it through PUBLIC.

ok    38 tables have explicit grants

2 errors, 1 warning. No credentials used.
.github/workflows/supabase.yml
- uses: Perufitlife/supabase-security-skill@main
  with:
    mode: migrations

Who does the work.

Renzo Madueño

Builder of supabase-security (MIT)

I run my own businesses on Supabase in production. I wrote supabase-security after auditing those projects and finding tables anyone could read with the anon key. The same tool does the first pass on your project; I review every grant and every policy by hand before the pull request goes out.

Questions before you buy? Email me. I answer myself.

  • Open source, MIT24 stars on GitHub. Read every check before you trust it.
  • Run on our own production apps firstIn a 139-table web app it found 17 tables with RLS off and full access for anon, fixed in one transaction. In a 55-table internal CRM, 13 lower-severity findings.
  • A real report, not a mockupOpen the sample report, generated from one of our own projects.

Questions before you buy.

Does this affect my app?

Yes if your app talks to Supabase through the Data API: supabase-js, any client library, or the REST and GraphQL endpoints. If you only connect with a Postgres connection string (an ORM, a server, psql), this change doesn’t touch you.

Will my app break on Oct 30?

No. Existing tables keep their grants. What fails is the next table, view or sequence someone adds to public without a grant (you, a teammate or an AI coding tool) and your migrations replayed on a new project. You’ll see 42501 permission denied for table: HTTP 401 for anon, 403 for signed-in users. An empty [] is a different problem: the grant is there and RLS hides the rows.

Why not just grant everything to anon?

A bulk grant to anon (it’s the rollback in Supabase’s own changelog) makes the error go away and gives anyone with your anon key access to every table without row level security. That’s the exposure this change exists to close. Grants belong per table and per role.

Can I do this myself?

Yes. Supabase’s changelog has the SQL and our linter shows what’s missing. Buy a plan if you want it written, checked against your RLS, verified with real API calls and merged before Oct 30 without spending your week on it.

What access do you need?

Your repo (invite GitHub user Perufitlife, or send a read-only token) and your Supabase project ref. We don’t need your service_role key or your database password. The live test in Hardening uses your public anon key and runs only after you say yes in writing.

Do you change my production database?

No. Everything arrives as a pull request. You review it, merge it and deploy it the way you always do.

Our tables were made in the dashboard, not in migrations.

That’s common. We read the live schema and write the migration that matches it, so your repo becomes the record of who can access what.

Who will the charge come from?

Stripe processes the payment under Rotate Pilot, our parent company, so that’s the name on the checkout and your statement. Need an invoice with your company details? Email us.

October 30 is a Friday. Have the grants merged before it.

Pull request within 48 hours of access, or a full refund.