DEV Community: Ahmed Hassan Yaseen

Supabase Realtime not firing? 7 checks when postgres_changes sends nothing

Ahmed Hassan Yaseen — Sat, 07 Nov 2026 11:18:15 +0000

You subscribe to a table, the status callback says SUBSCRIBED, a row changes in the database, and your app hears nothing. No error in the console, no event, just silence.

Supabase's own troubleshooting guide describes exactly this and says the cause is almost always one of a handful of things. Below are the checks in the order I'd run them, with the SQL and code for each. Everything here is taken from the Supabase Postgres Changes docs, their Postgres Changes troubleshooting guide, and their messages not arriving guide, all read on 7 November 2026.

First, a working baseline

This is the shape of a subscription that should fire for every change on one table:

const channel = supabase
  .channel('todos-changes')
  .on(
    'postgres_changes',
    { event: '*', schema: 'public', table: 'todos' },
    (payload) => console.log('Change received:', payload)
  )
  .subscribe((status) => console.log('Subscription status:', status))

Two details from the docs: the channel name can be any string except realtime, and event is one of INSERT, UPDATE, DELETE or *. Keep this bare version handy. If your real subscription has filters, you'll strip back to this later.

1. Is the table in the `supabase_realtime` publication?

Realtime doesn't watch every table by default. A table has to be added to a publication called supabase_realtime, and creating a table and enabling Realtime on it are two separate steps. That's easy to miss when a table was created by a migration or by an AI builder.

Check what's in the publication:

select * from pg_publication_tables where pubname = 'supabase_realtime';

If your table isn't listed, add it:

alter publication supabase_realtime add table todos;

You can also toggle it on in the dashboard under Database, then Publications.

2. Is Row Level Security quietly hiding the row?

Supabase calls this the most common cause by a wide margin, and the one that wastes the most time, because nothing errors.

Realtime enforces RLS as the subscribing client's role, the same way a normal query would. SUBSCRIBED only means the WebSocket connected. It says nothing about whether that user is allowed to see the row that changed.

The quickest test is to run a normal select with the same client and the same signed-in user:

const { data, error } = await supabase
  .from('todos')
  .select('*')
  .eq('id', idOfTheRowThatChanged)

console.log({ data, error })

If data is empty, that's your answer. Don't test this in the SQL Editor as postgres: that role bypasses RLS, so the row will always show up there.

The fix is a select policy that matches who should see the row. For a table where each row belongs to one user, it looks like this:

create policy "Users can read their own todos"
on todos for select
to authenticated
using ( (select auth.uid()) = user_id );

Two traps to know about:

UPDATE events need both states to pass. Supabase's guide notes that RLS generally has to allow both the old and the new row. If a policy only allows status = 'active' and an update flips the row to archived, the event can fail to arrive.
DELETE events are not filtered by RLS at all. The docs explain that Postgres has no way to check access to a row that's already gone. Keep that in mind before you put anything sensitive in a delete payload.

3. Tables outside `public` need a grant

Postgres Changes works out of the box for tables in the public schema. If your table lives in another schema, the docs say you also have to grant select on it to the role in the user's access token, for example:

grant select on my_schema.todos to authenticated;

There's no dashboard toggle for that grant. Supabase also strongly recommends turning on RLS and writing policies for those tables, because otherwise any role you grant can read the whole table.

4. Check the subscription itself, character by character

Once the publication and RLS are ruled out, look for small mismatches:

The table name matches exactly, including case.
The schema is right (public unless you use a custom one).
The filter uses Realtime's syntax: room_id=eq.abc123, not room_id = abc123.

Filters are column=operator.value expressions that Realtime evaluates on the server, so a filter that doesn't match means the event never leaves the database. Several conditions can be joined with commas, which works as AND; OR isn't supported.

Then log the status callback instead of assuming it worked. SUBSCRIBED means connected, CHANNEL_ERROR means read the error payload, CLOSED means the channel was shut down, and TIMED_OUT points to a connection problem. A channel that errors and a channel that connects but never fires are different problems, so work out which one you have.

If nothing turns up, Supabase's advice is to strip the subscription to the bare minimum: no filter and event: '*'. If that still never fires, it's a publication or RLS problem, not your filter.

5. Stale subscriptions in React and Next.js

If you see duplicate events, or events for the wrong room, a re-rendered component is probably leaving an old channel running. Clean it up when the component unmounts or the parameter changes:

useEffect(() => {
  const channel = supabase
    .channel(`room:${roomId}`)
    .on(
      'postgres_changes',
      { event: 'UPDATE', schema: 'public', table: 'messages', filter: `room_id=eq.${roomId}` },
      (payload) => console.log(payload.new)
    )
    .subscribe()

  return () => {
    supabase.removeChannel(channel)
  }
}, [roomId])

The removeChannel line in the cleanup is the part that usually goes missing.

6. Writing straight after `SUBSCRIBED`

This one bites automated tests most. Supabase confirms a short gap between the client reporting SUBSCRIBED and the server being ready to stream changes, so a write made in that gap can be missed. Their guide shows listening for the system message that says the postgres_changes extension is ready, and only then writing. A one-second delay after SUBSCRIBED is the weaker fallback they mention.

7. Events arrive, but `payload.old` is empty

If events do come through but payload.old only has the primary key, that's replica identity, not delivery. By default Postgres sends only the primary key as the old row for UPDATE and DELETE. To get the previous values:

alter table todos replica identity full;

Two caveats from the docs. On a table with RLS turned on, payload.old still contains only the primary key, even with replica identity full, so don't build logic that compares old and new values on a policy-protected table. And you can only filter DELETE events when the table's replica identity is full.

Still nothing?

Check that Realtime is enabled for the project, read the Realtime logs in the dashboard, and rule out a firewall or proxy that blocks WebSockets. Supabase's guide also lists an outdated supabase-js as a possible cause, so check you're on a recent version.

Finally, design for the odd missed event. Supabase says plainly that Realtime doesn't guarantee every message is delivered, because network blips and reconnects happen. Treat an event as a signal to re-fetch the data, not as the only source of truth.

Most of the silent cases come back to the same two things: the table was never added to the publication, or a policy that looked fine hides the row from the user who's listening. If you want a second pair of eyes on your policies and grants, I wrote up how to test them as a signed-out visitor and as two different users here: Is the Supabase anon key safe to expose?. And if you're about to launch, our free Launch Check looks at headers, exposed keys and more, with no sign-up.

I wrote this with AI assistance and reviewed it myself.

Vite env variable undefined in production? Set VITE_ before the build

Ahmed Hassan Yaseen — Sat, 07 Nov 2026 10:14:14 +0000

Your production app throws one of these:

import.meta.env.VITE_SUPABASE_URL is undefined
supabaseUrl is required
Cannot read properties of undefined

Vite replaces import.meta.env values when the app is built, and only variables that start with VITE_ reach browser code. Set those VITE_ variables on the host before the build runs, then rebuild. Keep anything secret out of VITE_ variables entirely.

I see this constantly in Lovable and Bolt apps the first time they leave the builder and land on Vercel, Netlify, or Cloudflare.

Why it happens

The variable was added after the build. Values are written into the bundle at build time, so adding a variable on the host does nothing until you rebuild.
Missing VITE_ prefix. Variables without that prefix are not exposed to client code, so they read as undefined in the browser. Vite's docs: variables prefixed with VITE_ are exposed in client-side source code after bundling.
Set for the wrong environment. The variable exists for preview builds but not production, or the other way round.
A .env file was not deployed. A .env.local file is meant to be git-ignored, so a host building from the repository never sees it.

Find the cause

Search the code for import.meta.env and list every variable it reads.
In the host's settings (Vercel, Netlify, Cloudflare), check each one exists for the production environment with the exact name.
Check the date of the last build against when the variables were added.

Fix 1: set the variables before building

Add each VITE_ variable in the host's environment settings for production.
Trigger a new deployment so the build reads them.

VITE_SUPABASE_URL=https://your-project.supabase.co
VITE_SUPABASE_PUBLISHABLE_KEY=sb_publishable_...
# never a secret key in a VITE_ variable

Fix 2: move secrets to the server

Anything secret (a Stripe secret key, a Supabase secret key, a third-party API key) belongs in a server or edge function's environment, not in a VITE_ variable. Vite compiles VITE_* values into the code the browser downloads, so anyone can read them. Vite's own docs say the same: do not put sensitive information in VITE_* variables.

Check the fix worked

Open the production site: the feature that needed the variable works.
Run a free Launch Check: https://stacksmesh.com/tools/launch-check?utm_source=devto&utm_medium=article&utm_campaign=BR-0003 — no secret keys found in the bundle.

Stop it coming back

Keep a .env.example file listing every variable the app needs, without values.
Fail the build when a required variable is missing, instead of failing in the browser.

Quick answers

Why does it work on Lovable and not on my host? Lovable sets the values for its own builds. A new host needs them set again, before its first build.

Are VITE_ variables hidden from users? No. They are in the downloaded JavaScript.

Full write-up with the same steps: https://stacksmesh.com/fix/vite-env-variable-undefined-in-production?utm_source=devto&utm_medium=article&utm_campaign=BR-0003

I wrote this with AI assistance and reviewed it myself.

Supabase Storage upload fails with "new row violates row-level security policy"? Here's the fix

Ahmed Hassan Yaseen — Mon, 02 Nov 2026 00:06:52 +0000

Your app tries to upload a file to Supabase Storage, and the request fails with one of these:

new row violates row-level security policy
StorageApiError: new row violates row-level security policy
Unauthorized

Supabase Storage refuses every upload until the storage.objects table has policies that allow it. The fix: add an INSERT policy for the bucket, scoped to the user's own folder, and add SELECT and UPDATE policies if the app overwrites files with upsert.

I see this one a lot in apps built with Lovable and Bolt on Supabase, usually the first time someone adds an avatar or document upload.

Why it happens

No policy on storage.objects. Supabase's docs say it plainly: "By default Storage does not allow any uploads to buckets without RLS policies." A new bucket starts closed.
Upsert needs more than INSERT. Overwriting an existing file (upsert: true) also needs SELECT and UPDATE policies.
The path doesn't match the policy. The policy expects files in a folder named after the user, but the app uploads to the bucket root or to a different folder.
The upload runs signed out. A policy that compares against the user's id fails for a request with no session.

Find the cause

Copy the exact error and note the bucket and the path the app uploads to.
In the Supabase dashboard, open Storage > Policies and list the policies for that bucket by operation.
Check whether the upload call passes upsert: true.
Confirm a session exists at the moment of upload.

Fix 1: let users upload into their own folder

Upload files to a path that starts with the user's id, for example avatars/<user-id>/photo.png. Then create an INSERT policy for that bucket that checks the first folder against the signed-in user, plus a SELECT policy so they can read their own files:

create policy "Users upload to their own folder"
on storage.objects for insert
to authenticated
with check (
  bucket_id = 'avatars'
  and (storage.foldername(name))[1] = (select auth.jwt()->>'sub')
);

create policy "Users read their own files"
on storage.objects for select
to authenticated
using ( bucket_id = 'avatars' and (select auth.jwt()->>'sub') = owner_id );

The sub claim in the JWT is the signed-in user's id, which is what Supabase's own examples use to match a user to their folder.

Fix 2: allow overwrites only where needed

If the app replaces files, add an UPDATE policy with the same folder check, alongside the SELECT policy:

create policy "Users overwrite files in their own folder"
on storage.objects for update
to authenticated
using (
  bucket_id = 'avatars'
  and (storage.foldername(name))[1] = (select auth.jwt()->>'sub')
)
with check (
  bucket_id = 'avatars'
  and (storage.foldername(name))[1] = (select auth.jwt()->>'sub')
);

If it doesn't need to replace files, upload with a new file name each time and leave upsert off. Fewer policies, fewer surprises.

Check the fix worked

Signed in as user A, upload a file: it succeeds and lands in A's folder.
Still as user A, try to upload into B's folder: it fails.
Signed out, try to upload: it fails.

All three matter. A policy that lets everything through also makes the first test pass.

Stop it coming back

Decide per bucket whether files are public or private before you build the upload screen.
Never upload from the browser with a secret or service key. It bypasses every policy.

Quick answers

Should the bucket be public? Only for files anyone may see, such as product images. Profile documents, invoices and user uploads belong in a private bucket with policies.

Why the JWT sub claim? It is the signed-in user's id, which Supabase's own examples use to match a user to their folder.

Source: Supabase: Storage access control.

I first published this fix on our site: Supabase Storage upload "new row violates RLS": fix with SQL. To check your live app for exposed keys, missing security headers and broken basics in about a minute, run the free Launch Check.

I wrote this with AI assistance and reviewed it myself.

How much does it cost to fix a Lovable or Base44 app?

Ahmed Hassan Yaseen — Sun, 01 Nov 2026 00:12:13 +0000

"How much will it cost to fix my app?" is the question I get most from founders who built with Lovable or Base44. The honest answer is "it depends", which isn't useful on its own. So here are the ranges from the prices we publish: what finding the problems costs (nothing, to start), what one fix and a handful of fixes come to on a worked example, what a launch-ready app costs, and when a rebuild is cheaper than fixing.

The short version

Finding out is free. The Launch Check reads a live app in about a minute with no sign-up, and the AI audit reads the code: three audits per account, with a price range for every fix it finds.
On a worked example (a small Lovable booking app with five findings), the cheapest single fix comes to $200–$225 and the dearest to $875–$1,625. All five together come to $1,175–$2,175, far less than the five fixed one at a time.
Making the whole app ready for paying customers is App Launch Readiness, from $2,499. App Store submission starts at $499 per store, and monthly support for a Base44 app is $399.
A rebuild is cheaper when the fixes touch most of the app, the data model is wrong at the root, or the first version is small: a Starter MVP on Base44 or Lovable starts at $1,499, a code-owned MVP Build at $9,999.

It depends on the app, so look first

What a fix costs depends on what is broken, how much of the app it touches and how many things you fix at once. An honest price starts with a look at the app, and that look should cost nothing. These are the prices we publish (USD, starting prices, fixed in writing after review, as of 23 October 2026), so you can place your app on the scale before you talk to anyone:

What you need	Published price	What it covers
Find out what is wrong	Free	The Launch Check on a live app, no sign-up. Three AI code audits per account, every finding tied to a file and line, with a price range per fix; further audits from $19.
A written assessment or proposal	From $150	A focused review, or the scope and fixed price on paper. Credited in full when the work starts; the first conversation is free.
One fix, or a handful	Priced from the audit	The fix plan gives the range; an engineer confirms the scope and gives one fixed price in writing.
The whole app ready for paying customers	From $2,499	App Launch Readiness: review and priorities, stability and agreed fixes, broken workflows repaired and tested, launch checks, release and handover.
Published on the App Store or Google Play	From $499 per store; both from $799	Review-guideline fixes, the listing, and resubmission until approved, in your developer accounts. Apple's and Google's fees are separate.
Fixes and improvements every month	$399 a month	App Partner: one existing Base44 app, 8 team hours a month.
Moving to accounts you own	From $1,999 (Lovable) or $2,999 (Base44)	Code, data, users, files and access rules moved and tested, with a cut-over and rollback plan.
Rebuilding the first version	From $1,499 (Starter MVP) or $9,999 (MVP Build)	A Starter MVP is rebuilt on Base44 or Lovable around one core journey; an MVP Build is engineered in code you own.

A worked example: five findings, priced

Our free AI audit page has a fix planner you can try on example findings from a small fitness-studio booking app built with Lovable. It's an example, not a client. Each total is what the planner shows for that selection, worked out the way every report does it: learning the project, the fix itself, testing and release. They're AI estimates, not quotes.

Fixing	What goes wrong today	Example total
The price comes from the browser (High)	Anyone can book a class for $1.	$875–$1,625
Bookings work without signing in (High)	Strangers can fill your classes.	$575–$1,050
A retried payment books twice (Medium)	One payment, two bookings.	$325–$600
Class names are not escaped in emails (Medium)	A crafted name can inject HTML.	$250–$450, includes project onboarding
A class can be booked past capacity (Low)	Two people get the last spot.	$200–$225, includes project onboarding
The two High findings together	Payments and sign-in	$1,000–$1,850
All five together	Everything above	$1,175–$2,175

Three things stand out:

Batches cost less. Add up the five single totals and you get far more than the all-five total, because learning the project, testing and release are shared across the fixes.
Money and access cost the most. The two High findings are most of the bill, because payments and access rules have to be tested as each kind of user and in payment test mode.
Small fixes are small. An isolated fix, like escaping one email template, comes to a few hundred dollars in all.

What drives the cost

How much of the app the problem touches. A missing check in one place is one fix. The same missing check on every screen is still one fix, applied and tested everywhere, and we price a repeated pattern once.
Money and personal data. Payments, webhooks, sign-in and access rules need more testing than a layout change.
The size of the app. Every estimate includes the hours to learn the project, scaled to its screens, data and integrations.
How many fixes you do at once. Shared work is paid for once per batch, not once per fix.
Whether the app has tests. Without them, every fix needs more checking of the journeys around it.
What's not in the price unless the proposal says so: hosting, platform subscriptions and credits, AI usage, paid tools and taxes.

When a rebuild is cheaper than fixing

Compare the audit's total for everything you'd fix with the price of building the same first version again. When the two come close, price the rebuild too: you get a clean foundation for the same money. Rebuild when:

the fixes touch most of the app, not a few journeys;
the data model is wrong at the root (the same data written from many places, or business rules copied into every screen);
the first version is small: one audience and one core journey, with few real users or records to move;
you need something the platform can't give you, like your own backend or hosting. Then compare a migration with a rebuild.

Fixing is cheaper when the problems sit in a few workflows, you can say what should happen and show where it fails, the platform supports the feature and it was just configured or built wrongly, and paying users and real data are already in the app.

How to get your own number

Run the free Launch Check on the live app: about a minute, no sign-up.
Run the free AI audit on the code: paste a GitHub link, connect GitHub or upload a ZIP. Tick the findings you want fixed and the fix plan shows the range.
Send the plan to us. An engineer confirms the scope and gives one fixed price in writing before any work starts.

Whoever you hire, ask for written acceptance checks. Ours come with every fixed-price project, and for 30 days after handover, if something we fixed breaks again without anyone changing it, we fix it free.

I first published this on our site, with the latest prices: How much does it cost to fix a Lovable or Base44 app?. To get a price range for your own app, run the free AI audit on your code.

I wrote this with AI assistance and reviewed it myself.

What "production-ready" means for an AI-built app, in 32 checks

Ahmed Hassan Yaseen — Sat, 31 Oct 2026 11:08:06 +0000

AI app builders make the demo path work in hours. I see it every week: a founder opens a Lovable, Base44, Bolt or Replit app, signs up, clicks through the main flow, and it works. The hard question comes after that. In the words of the standard we published: "What decides whether an app can carry a business is everything the demo never tested: who can read which records, what happens when a payment webhook fails, whether a secret key shipped to the browser, and whether the owner can run the app without the builder."

"Production-ready" gets used loosely, so we wrote it down. This post walks through what it means, one check from each area, and how to use the list before you launch or hire someone.

The definition in one sentence

Here is the definition the standard starts from:

"A production-ready app is one real customers and the business can rely on: it shows each person only their data, takes payments correctly, survives failures, and is owned by the business that runs it."

That turns into 32 checks in ten areas. The security checks are mapped to the OWASP Top 10:2025, and every check says how it is verified.

Ten areas, one check from each

I picked the check from each area that I find fails most often or matters most. The wording below is quoted from the standard.

1. Access to data (OWASP A01 Broken Access Control). The standard calls this "the most common serious failure in AI-built apps: rules that let one user read or change another user's records." PR-01 passes when "every table holding personal or business data has access rules for create, read, update and delete." On Supabase that means Row Level Security with a policy for each operation, not just one for reads.

2. Secrets and configuration. PR-05: "No secret API keys (for example a Supabase secret or service-role key, Stripe secret key) in code sent to the browser." A publishable key in the frontend is fine; a secret key there is not.

3. Sign-in (OWASP A07). PR-10: "Sign-up, email confirmation, password reset and social sign-in complete on the production domain, with redirect addresses configured." In the apps we check, this is often the one that breaks when an app moves from its preview URL to its own domain.

4. Payments (OWASP A08). PR-13: "Payment webhooks verify the provider's signature before acting." Its neighbour PR-14 matters just as much: "Each payment grants access or credit exactly once, even on retries or page refreshes."

5. Inputs, integrations and AI features. PR-19 is new territory for many apps: "Prompts cannot make an AI feature act beyond the signed-in user's permissions, and AI spend has a limit."

6. Dependencies (OWASP A03). PR-20: "A lockfile is committed, and every package the AI added exists and is the intended one." Before you trust a package an AI added, look it up in the registry and confirm it's the one you meant.

7. Reliability. PR-24 is short: "Backups exist, and a restore has been tested." A backup nobody has restored is a hope, not a backup.

8. Speed and search (Google Core Web Vitals). PR-25: "Largest Contentful Paint is 2.5 seconds or less on mobile." That threshold comes from Google's Core Web Vitals guidance. PR-27 covers the basics search engines and AI assistants need: "Each public page has its own title, description and canonical address; robots.txt and a sitemap exist; key content is in the HTML."

9. Store readiness. PR-29: "A privacy policy, in-app account deletion where accounts exist, explained permissions and real content, with no placeholder screens." The standard lists Apple's App Review Guidelines as its source for this area.

10. Ownership. The standard puts it plainly: "An app the business depends on must be one the business controls." PR-31: "Database, domain, hosting, payment and email accounts belong to the business, not to a freelancer."

The other 22 checks fill in each area: tested rules (PR-02), server-side role checks (PR-03), HTTPS and security headers (PR-06, PR-07), rate-limited sign-in (PR-12), reconciled payment records (PR-15), alerts when something fails (PR-23), and an exportable data path with a short runbook (PR-32), among others.

Why "pass or fail" wording matters

The part of the standard I care about most is this line: "Every check is specific enough to pass or fail, and every check names how it is verified, so two people checking the same app reach the same answer."

"Make it secure" can't be checked. "Payment webhooks verify the provider's signature before acting" can. Each check names one of four ways it is verified:

Automatically by the free Launch Check, which reads your live app the way a browser sees it. That covers PR-05 to PR-09 (secrets, HTTPS, headers, exposed files, cookies) and PR-25 to PR-28 (speed, layout shift, findability, accessibility).
By the free AI audit of the code, for checks that need the source: access rules, server-side role checks, webhook verification, input validation.
By the App Store readiness check, for store billing (PR-16) and review readiness (PR-29).
By an engineer, for things only a person can test: rules tried as another user and as a signed-out visitor (PR-02), sessions ending when they should (PR-11), a restore that actually works (PR-24), accounts in the company's name (PR-31).

That split is honest about what an automated tool can and can't tell you. A scanner can see a missing Content-Security-Policy header. It can't see whether your orders table lets user A read user B's rows. You need both kinds of check.

How to use it

The standard suggests four uses, and they match how I'd use it myself:

Before launch: "run the free Launch Check for the automatic checks, then the free AI audit for the code checks."
With a developer: "attach the check numbers to the scope as acceptance criteria." Instead of "fix the security", the scope says "PR-01, PR-03, PR-13 pass", and both sides know what done looks like.
Comparing offers: "ask each provider which checks their work covers and how they prove it."
After launch: "re-run the automatic checks after every publish; most regressions are a header, a key or a rule changed by a later prompt."

That last one is easy to skip. With AI builders, every new prompt can touch code you thought was finished. A rule that passed last week can fail after an unrelated change.

Where to start

If you have an app live today, start with the checks a machine can run in a minute, then work down the list. The full standard, with all 32 checks, the OWASP mapping and how each is verified, is here: The Production-Ready Standard for AI-built apps. It's free to use, cite and check against.

For the automatic checks, our free Launch Check runs them on your live app in about a minute, no sign-up.

I wrote this with AI assistance and reviewed it myself.

Stripe webhook "No signatures found matching the expected signature"? Here's the fix

Ahmed Hassan Yaseen — Tue, 27 Oct 2026 00:13:43 +0000

Stripe sends a webhook to your endpoint, and the delivery fails with one of these:

No signatures found matching the expected signature for payload
Webhook signature verification failed
SubtleCryptoProvider cannot be used in a synchronous context

Stripe signs the exact bytes it sends. If your code parses the JSON before verifying, or uses the wrong signing secret, the signature no longer matches. The fix: read the raw body as text, verify it with constructEventAsync and the endpoint's own whsec_ secret, and only then parse the event.

I see this one a lot in apps built with Lovable, Bolt and Base44 on Supabase, usually when payments move from the Stripe CLI to a real endpoint.

Why it happens

The body was parsed before verification. Calling req.json() and re-stringifying changes whitespace and key order, so the signature no longer matches.
The wrong signing secret. Each endpoint has its own whsec_ secret, test and live mode differ, and the Stripe CLI uses another one for local forwarding.
Synchronous verification in Deno. Edge Functions run on Deno and need constructEventAsync with the SubtleCrypto provider; the synchronous method throws.
A proxy or platform rewrote the request. A layer in between dropped the Stripe-Signature header or changed the body.

Find the cause

In Stripe, open the endpoint under Webhooks and read the failed delivery's response body.
Confirm which mode (test or live) the event came from, and which secret the function reads.
Log whether the Stripe-Signature header arrives at all.

Fix 1: verify the raw body in a Supabase Edge Function

Store the endpoint's signing secret as a function secret (for example STRIPE_WEBHOOK_SIGNING_SECRET). Read the body with req.text(), verify it with constructEventAsync and the SubtleCrypto provider, then handle the event.

import Stripe from 'npm:stripe@^22'

const stripe = new Stripe(Deno.env.get('STRIPE_API_KEY')!)
const cryptoProvider = Stripe.createSubtleCryptoProvider()

Deno.serve(async (req) => {
  const signature = req.headers.get('Stripe-Signature')
  const body = await req.text() // the exact bytes Stripe signed
  let event
  try {
    event = await stripe.webhooks.constructEventAsync(
      body, signature!, Deno.env.get('STRIPE_WEBHOOK_SIGNING_SECRET')!, undefined, cryptoProvider
    )
  } catch (err) {
    return new Response((err as Error).message, { status: 400 })
  }
  // handle event.type here, and make it safe to receive twice
  return Response.json({ received: true })
})

The important line is await req.text(). Stripe's docs are blunt about it: verification needs the raw request body, and any manipulation of that body makes it fail.

Deploy the function with JWT verification off. Stripe proves itself with the signature, not with a Supabase token. Supabase's own example deploys it with supabase functions deploy --no-verify-jwt stripe-webhooks.

Fix 2: match secrets to environments

Use the live endpoint's secret in production and the test endpoint's secret in staging. Stripe generates a unique secret for each endpoint, and the test and live secrets are different.
When forwarding with the Stripe CLI, use the secret that stripe listen prints.

Check the fix worked

Send a test event from the Stripe dashboard: the delivery shows 200.
Change one character of the secret: the delivery fails with 400. That proves the check is real.
Pay with a test card end to end and confirm the order or subscription updates in your database.

Stop it coming back

Handle each event idempotently (store the event id), because Stripe retries.
Reconcile with the Stripe API every day, so a missed webhook never leaves an order unpaid in your system.

Quick answers

Can I skip signature verification? No. Without it, anyone can post a fake "payment succeeded" event to your endpoint and unlock paid features.

Why did it work locally? The Stripe CLI uses its own signing secret. Production needs the secret of the endpoint registered in the dashboard.

Sources: Stripe: Check the webhook signatures and Supabase example: Stripe webhooks in an Edge Function.

I first published this fix on our site: Fix "No signatures found matching the expected signature" from Stripe. To check your live app for exposed keys, missing security headers and broken basics in about a minute, run the free Launch Check.

I wrote this with AI assistance and reviewed it myself.

Is the Supabase anon key safe in your frontend? What actually protects your data

Ahmed Hassan Yaseen — Mon, 26 Oct 2026 01:13:11 +0000

If you've built an app with Lovable, Bolt or any other tool that sits on Supabase, open your live site, view the JavaScript it sends, and search for supabase.co. Right next to it you'll find a key. The first time founders see this, the question is always the same: is my database key just sitting in public?

Short answer: that key is meant to be public. What it can reach is decided by your Row Level Security policies, and that's where things go wrong. Here's what the key does, which key must never ship, and three checks that tell you whether your data is actually protected.

Which key is in your JavaScript?

Supabase has two kinds of API keys, and the Supabase API keys guide picks between them by asking where the code runs:

Publishable key (sb_publishable_..., or the legacy anon key): for "anything you ship: browser, mobile app, CLI, script". The docs call it "safe to expose online", because "anyone can read it, so it only reaches what Row Level Security allows."
Secret key (sb_secret_..., or the legacy service_role key): for "anything you control: server, Edge Function, cron job". It "bypasses Row Level Security, so it must never leave your control."

If the key you found is a long string starting with eyJ, it's one of the legacy JWT keys. Supabase says it is "deprecating the anon and service_role keys by the end of 2026" in favour of the new publishable and secret keys, and both systems keep working side by side until you switch the old ones off. A lot of AI-generated code still uses the legacy names, so you'll see anon and service_role in plenty of projects for a while yet.

So the key itself isn't the problem. The question is what anyone holding it is allowed to do.

What the public key can do depends on your policies

Every request that uses the publishable key runs as one of two Postgres roles: anon when nobody is signed in, and authenticated when a user has signed in through Supabase Auth. Your Row Level Security (RLS) policies are rules attached to those roles, and Postgres applies them to every query.

The Supabase RLS guide is blunt about what happens without them: "A table in an exposed schema without RLS is readable and writable by any role with a grant on it" (Supabase: Row Level Security). In other words, if a table in your public schema has RLS switched off, anyone who copies the key out of your JavaScript can read it, and possibly change it, with a few lines of code.

This isn't theoretical. In 2025 a security researcher checked 1,645 apps from Lovable's public showcase and found 170 whose Supabase tables could be read or changed with the public key, because RLS was missing or too open. It was filed as CVE-2025-48757. Lovable disputes the CVE, saying each app owner is responsible for their data, and has since added a security scan before publishing.

In the apps we check, the gaps usually come from one of three places:

A table created by SQL or a migration, where RLS was never switched on.
A policy that says "anyone", often added to make an error go away, like using (true) on a table that holds personal data.
The secret key in the browser, put there by a quick fix so a failing insert would work. That one skips every policy you wrote.

Check 1: is RLS on for every table?

In the Supabase dashboard, open the Table Editor and look at each table in the public schema, or run this in the SQL editor:

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

Any row with rowsecurity = false is a table the public key can reach without rules. Turn it on:

alter table public.orders enable row level security;

Once RLS is enabled, the docs say "no data is accessible through the API when using a publishable key, until you create policies." So expect parts of your app to go quiet until you add the policies it needs. That's the safe direction to fail in.

The guide adds one more step that's easy to miss: "On projects that still grant anon and authenticated by default, revoke those grants. Adding policies doesn't remove them." Then grant back only what each role actually does in your app.

Check 2: do your policies limit rows to their owner?

RLS being on isn't enough if the policy lets everyone through. Look for policies on tables with user data that use true, or that are granted to anon when only signed-in users should see the data. A typical owner-only read policy from the Supabase docs looks like this:

create policy "Users can view their own profile."
on profiles for select
to authenticated
using ( (select auth.uid()) = user_id );

auth.uid() returns the ID of the signed-in user making the request, so each person only gets rows that carry their own ID. Do the same for insert, update and delete, each in its own policy, so a user can't write rows under someone else's ID.

Then test it the way an attacker would, as three different people:

Signed out, using only the publishable key: you should get no private rows.
As user A: you see A's rows.
As user B: you don't see A's rows, and you can't update them.

An empty result for the wrong user is what you want. One thing that trips people up: the docs note that a missing grant returns a permission error, while a policy that matches no rows returns an empty list. If a request fails that your policy should allow, check the grant before you change the policy.

Check 3: is a secret key anywhere it shouldn't be?

Search the JavaScript your live site sends, and your repository including its history, for sb_secret_ and service_role. Also check your environment variables: any variable prefixed for the browser, such as VITE_ or NEXT_PUBLIC_, ends up in the build that ships to every visitor. Supabase's own example puts it in a comment: "Server-only. Never prefix these, or your bundler will ship the key."

The new secret keys add a safety net: "A secret key doesn't work in a browser", because Supabase returns 401 Unauthorized when the request comes from one. But the docs are clear that it isn't protection once a key has leaked: "an attacker can still use the key from other tools."

If you find one, the order matters. Supabase's advice is "Fix the root cause of the leak before you rotate anything." Move the work that needed elevated rights into an Edge Function or server route that checks who's calling, give the browser only the publishable key, then create a new secret key, switch every component to it, and only then delete the leaked one. If the leaked key is the legacy service_role key, you can't delete it: deactivate it in the API Keys settings instead (that can be undone). Deleting a secret key can't be undone. I wrote up that sequence step by step in our fix for an exposed service_role or secret key.

The short version

The key in your JavaScript is supposed to be there. What keeps your data safe is RLS on every table, policies that limit each row to the people who should see it, and a secret key that never leaves your server. Supabase's own checklist adds one habit: review your policies regularly and run the Security Advisor in the dashboard, which "checks for common security problems with the built-in Postgres roles."

If you'd like a quick outside look first, our free Lovable security check reads your live app in about a minute, no sign-up, and flags a Supabase service key or other secrets in your public JavaScript and missing security headers. It only sees what a browser sees, so the RLS tests above are still yours to run.

Full checklist with SQL and tests: stacksmesh.com/fix/supabase-anon-key-exposed

I wrote this with AI assistance and reviewed it myself.

Supabase Edge Function blocked by CORS policy? Here's the fix

Ahmed Hassan Yaseen — Mon, 26 Oct 2026 00:08:03 +0000

You call a Supabase Edge Function from your app and the browser console shows one of these:

has been blocked by CORS policy
Response to preflight request doesn't pass access control check
No 'Access-Control-Allow-Origin' header is present on the requested resource

Before your real request, the browser sends an OPTIONS preflight. Either the function doesn't answer it, or it answers without the CORS headers. The fix: answer OPTIONS with the headers, and attach the same headers to every response, errors included.

I see this one a lot in apps built with Lovable and Bolt on Supabase, usually the first time a function is called from the browser instead of from the dashboard.

Why it happens

OPTIONS isn't handled. The function treats the preflight like a normal call, fails to parse a body, and returns an error without headers.
Errors skip the headers. The success path returns CORS headers, but a thrown error or a 400 doesn't, so the browser reports CORS instead of the real error.
A header isn't allowed. The client sends a header (for example x-client-info or a trace header) that's missing from Access-Control-Allow-Headers.
The function crashed. A function that fails to boot returns no headers at all, and the CORS message hides the crash.

Find the cause

In the browser's network tab, find the OPTIONS request and check its status and headers.
Open the function's logs in the Supabase dashboard. A crash or a thrown error shows up there, not in the browser.
Call the function with curl. If it fails there too, the problem is the function, not CORS.

Fix 1: use the SDK's headers and answer the preflight

With supabase-js 2.95.0 or later, you can import the CORS headers from the SDK, so they stay in sync with the headers the client sends. Return them on the OPTIONS response and on every other response, then redeploy.

import { corsHeaders } from 'npm:@supabase/supabase-js@^2/cors'

Deno.serve(async (req) => {
  if (req.method === 'OPTIONS') {
    return Response.json({ ok: true }, { headers: corsHeaders })
  }
  try {
    const { name } = await req.json()
    return Response.json({ message: 'Hello ' + name }, { headers: corsHeaders })
  } catch (error) {
    const message = error instanceof Error ? error.message : 'Bad request'
    return Response.json({ error: message }, { status: 400, headers: corsHeaders })
  }
})

The catch branch is the part people skip. Without headers on the error response, a simple bad request looks like a CORS failure in the browser.

The Supabase docs also describe a withSupabase wrapper that handles CORS and the preflight for you, if you'd rather not add the headers by hand.

Fix 2: narrow the allowed origin before launch

Access-Control-Allow-Origin: * is fine for public functions. For functions that act on a signed-in user, return your own domain instead.

Check the fix worked

In the network tab, the OPTIONS request returns 200 with Access-Control-Allow-Origin.
Trigger an error on purpose (send a bad body). The browser should now show your error message, not a CORS error.

Stop it coming back

Wrap every function in one helper that adds the headers, so a new function can't forget them.
Read the function logs whenever the browser reports CORS. It's often a crash in disguise.

Quick answers

Why does it work with curl but not in the browser? curl doesn't enforce CORS and sends no preflight. Only browsers check the headers.

Do I need CORS for webhooks? No. Webhooks come from servers (Stripe, for example), which ignore CORS. They need signature checks instead.

Source: Supabase: CORS support for Edge Functions.

I first published this fix on our site: Fix CORS errors when calling a Supabase Edge Function. To check your live app for exposed keys, missing security headers and broken basics in about a minute, run the free Launch Check.

I wrote this with AI assistance and reviewed it myself.

Google sign-in fails with redirect_uri_mismatch on Supabase? Here's the fix

Ahmed Hassan Yaseen — Sun, 25 Oct 2026 00:08:17 +0000

You add "Sign in with Google" to your app, click the button, and Google shows one of these instead of the account picker:

Error 400: redirect_uri_mismatch
Access blocked: This app's request is invalid
Unable to exchange external code

Google only sends users back to addresses listed in your OAuth client. With Supabase, that address is your project's auth callback, not your app. So the fix is: add the callback URL shown on the Supabase Google provider page to Authorized redirect URIs, add your site to Authorized JavaScript origins, and allow your app's return page in Supabase.

I see this one often in apps built with Lovable and Bolt on Supabase, usually the first time someone sets up Google sign-in for the live domain.

Why it happens

The Supabase callback is missing in Google Cloud. Authorized redirect URIs lists your app's address instead of the Supabase callback (https://<project-ref>.supabase.co/auth/v1/callback, or your custom auth domain).
You edited the wrong OAuth client. The client ID and secret in Supabase belong to a different Google Cloud client than the one you changed, or the client type isn't Web application.
The return page isn't allowed in Supabase. After Google, Supabase sends the user to your redirectTo address. If that address isn't on the Redirect URLs list, users land on the Site URL instead.
The audience is limited. While the Google consent screen is set to testing or internal users, anyone outside the allowed list is blocked.

Find the cause

On Google's error page, click error details and copy the redirect_uri value it shows.
In Supabase, open Authentication > Providers > Google and copy the callback URL shown there.
In Google Cloud, open Google Auth Platform > Clients, open the client whose ID matches the one in Supabase, and compare the two.

Fix 1: correct the Google Cloud client

Under Authorized redirect URIs, add the exact callback URL from the Supabase Google provider page.
Under Authorized JavaScript origins, add your site's origin only, for example https://app.example.com, with no path.
Save, and make sure this client's ID and secret are the ones in the Supabase Google provider.

Fix 2: allow the page users come back to

Add your return page (for example https://app.example.com/auth/callback) to Redirect URLs in Supabase, then pass it from the app:

await supabase.auth.signInWithOAuth({
  provider: 'google',
  options: { redirectTo: window.location.origin + '/auth/callback' },
});

Fix 3: open sign-in to everyone

In Google Auth Platform, set the audience to external and publish the app when you're ready for public users. Brand verification can take a few business days, so don't leave it to launch day.

Check the fix worked

Sign in with a Google account that has never used the app. It should come back to your callback page, signed in.
Sign out, then sign in again from a private window and from a phone.
Remove any localhost origins from the production client.

Stop it coming back

Use one Google client per environment (development and production), so a change for one can't break the live app.
Before launch, set up a custom auth domain so the Google screen shows your domain instead of supabase.co.

Quick answers

Should the redirect URI be my app or Supabase? Supabase. Google sends the user to Supabase's callback, and Supabase then sends them on to your app's redirectTo address.

How long do Google changes take? Usually a few minutes. Test in a private window so an old session doesn't hide the result.

Sources: Supabase: Login with Google and Supabase: Redirect URLs.

I first published this fix on our site: Fix Google sign-in redirect_uri_mismatch with Supabase. To check your live app for exposed keys, missing security headers and broken basics in about a minute, run the free Launch Check.

I wrote this with AI assistance and reviewed it myself.

Supabase confirmation or reset email opens localhost:3000? Here's the fix

Ahmed Hassan Yaseen — Sat, 24 Oct 2026 11:07:25 +0000

A user signs up for your live app, clicks the confirmation link, and the browser says:

localhost:3000 refused to connect

Password reset emails do the same. Nothing is wrong with your deploy. Supabase builds email links from the project's Site URL, and a new project starts with that set to http://localhost:3000. Set the Site URL to your live domain, add every address you redirect to under Redirect URLs, and pass a redirect address from the app that is on that list.

I see this a lot in apps built with Lovable, Bolt and Replit on Supabase, usually right after the first real users arrive.

Why it happens

The Site URL is still the default. Every confirmation and reset link falls back to it, so they all point at localhost:3000.
The redirect address isn't allowed. If the app asks Supabase to redirect somewhere that isn't on the Redirect URLs list, Supabase uses the Site URL instead.
A customised email template uses {{ .SiteURL }}. That ignores the redirect you passed. Templates for redirect flows should use {{ .RedirectTo }}.

Find the cause

Open the email and hover the button. Note the exact address it opens.
In the Supabase dashboard, open Authentication > URL Configuration and read the Site URL and the Redirect URLs list.
Find where your app calls signUp, resetPasswordForEmail or signInWithOtp and check which redirect address it passes, if any.

Fix 1: set the Site URL and the allow list

Set Site URL to your production address, for example https://app.example.com.
Add the exact pages you redirect to, such as https://app.example.com/auth/callback and https://app.example.com/reset-password.
Keep http://localhost:3000/** only if you still develop locally. Supabase recommends exact paths in production rather than wildcards.

Fix 2: pass the redirect address from the app

Build the address from the current site, so previews and production both work:

await supabase.auth.resetPasswordForEmail(email, {
  redirectTo: window.location.origin + '/reset-password',
});

await supabase.auth.signUp({
  email,
  password,
  options: { emailRedirectTo: window.location.origin + '/auth/callback' },
});

Whatever window.location.origin resolves to on each environment has to be on the Redirect URLs list, or Supabase falls back to the Site URL again.

Fix 3: check customised email templates

In Authentication > Email Templates, replace {{ .SiteURL }} with {{ .RedirectTo }} in the templates whose flow passes a redirect address.

Check the fix worked

Sign up with a fresh email address: the confirmation link opens your live site and signs the user in.
Request a password reset: the link opens your reset page on the live domain.
If you use a preview or staging address, repeat once there to confirm its pattern is allowed.

Stop it coming back

Put the Site URL and Redirect URLs on your launch checklist. Both are set per project, so a new project starts at the default again.
Set up a custom sending domain for auth emails before launch so they reach inboxes.

Quick answers

Do I need to redeploy after changing the Site URL? No. It's a project setting and new emails use it right away. Emails already sent keep their old links, so ask affected users to request a new one.

What about a mobile app? Use a deep-link address such as com.example.app://login-callback as the redirect and add it to the Redirect URLs list.

Source: Supabase: Redirect URLs.

I first published this fix on our site: Supabase confirmation or reset email links to localhost: the fix. To check your live app for exposed keys, missing security headers and broken basics in about a minute, run the free Launch Check.

I wrote this with AI assistance and reviewed it myself.

Before you launch a Lovable or Replit app, check these four things

Ahmed Hassan Yaseen — Tue, 20 Oct 2026 01:19:10 +0000

Most of the AI-built apps I look at before launch basically work. What they're missing is the stuff you can't see from inside the app: pages Google can't read, a phone load time nobody tested, and headers the browser never mentions. We recently put numbers on how common that is, and these are the four checks I'd run on any Lovable or Replit app before telling people about it.

The numbers come from our State of AI-Built Apps 2026 report: "On 18 October 2026 we ran a passive check on every app listed in two public showcases: 533 from madewithlovable.com and 224 from the Replit community showcase. 578 of the 757 were still online." A passive check means we only read what any visitor's browser receives: the home page, its response headers, the JavaScript it sends, robots.txt and the sitemap. It can't see your database rules, sign-in or payments, so a clean result here isn't a security audit. But these four gaps are easy to find and usually cheap to close.

1. Can Google and AI assistants read your pages?

From the report: "Most of these apps are hard for search engines and AI assistants to read: 76% of the Lovable apps send crawlers an almost empty HTML page, and about half of all apps have no sitemap."

Lovable and most Vite apps render in the browser. The HTML your server sends is an empty <div id="root"> plus a script, and the words appear only after JavaScript runs. Google says it handles JavaScript apps in three phases (crawling, rendering and indexing) and that Googlebot queues pages for rendering, so there can be a delay before your content is seen. The same page adds that server-side or pre-rendering "is still a great idea because it makes your website faster for users and crawlers, and not all bots can run JavaScript" (Google Search Central: JavaScript SEO basics).

How to check: open your key pages with view-source (not the inspector, which shows the page after JavaScript). Search for a sentence from your hero section. If it isn't in the source, a crawler that doesn't run JavaScript sees a blank page.

How to fix: you don't need to rewrite the app. Prerender the pages that should be found (home, pricing, features, blog), give every route its own title and description, and use real <a href> links for navigation rather than click handlers, so crawlers can follow them. Your app screens behind a login can stay client-rendered.

2. A sitemap Google can find

About half the apps had none, and it's the easiest fix on this list. A sitemap tells Google which pages exist, which matters most for new and deep pages.

How to check: open https://your-domain.com/sitemap.xml and https://your-domain.com/robots.txt.

How to fix: write a sitemap.xml that lists every public URL and put it in Vite's public/ folder. Vite copies that folder to the root of the build as-is (Vite: the public directory). A single sitemap can hold up to 50,000 URLs or 50MB uncompressed. Then tell Google where it is in two ways: submit it in Search Console, and add a line like Sitemap: https://your-domain.com/sitemap.xml to robots.txt (Google: build and submit a sitemap). Only list pages you want found, not dashboards or settings screens.

3. How fast it loads on a phone

From the report: "In a sample of 139 apps tested for mobile speed, the main content took a median of 5.0 seconds to appear, and 87% were slower than the 2.5 seconds Google treats as good."

That measure is Largest Contentful Paint (LCP): how long until the biggest thing on screen, usually your hero image or headline, shows up. web.dev puts it plainly: "A good LCP value is 2.5 seconds or less" (web.dev: LCP).

How to check: run your home page through PageSpeed Insights on the mobile tab. Its lab data comes from Lighthouse and simulates a page load (PSI docs); if your site has enough real visitors, it also shows field data.

How to fix: in the report, the usual causes were JavaScript the page doesn't use and resources that block rendering. In a Vite app that often means one big bundle that has to download before anything appears. Split heavy routes with React.lazy, which defers a component's code "until it is rendered for the first time" (React docs), so the landing page doesn't wait for the admin dashboard. Make the hero image discoverable in the HTML, sized for phones, and give it fetchpriority="high", as web.dev recommends for the LCP image (web.dev: Optimize LCP). Prerendering from check 1 helps here too, because the headline arrives with the HTML.

4. Two security headers: Content-Security-Policy and frame protection

From the report: "Security headers are the most common gap. 93% of the live Lovable apps and 79% of the live Replit apps send no Content-Security-Policy, and 91% and 72% have no protection against being loaded inside another site's frame."

What they do:

A Content-Security-Policy (CSP) tells the browser where your page may load scripts, styles, images and network requests from. MDN describes it as a defence against cross-site scripting, where injected code runs as if it were yours (MDN: CSP guide).
Frame protection stops another site from loading your app inside an invisible iframe and tricking people into clicks (clickjacking). The modern way is the CSP directive frame-ancestors (MDN: frame-ancestors); X-Frame-Options: DENY is the older header that covers older browsers (MDN: X-Frame-Options).

How to check: run curl -I https://your-domain.com and look for content-security-policy and x-frame-options in the output. If neither is there, you're in the majority.

How to fix: a Vite build is a folder of static files, so these headers come from your host, not your React code. On Vercel they go in vercel.json (Vercel docs); on Netlify, in a _headers file (Netlify docs). The frame headers are safe to switch on straight away if you don't embed your own app anywhere. Here's a Netlify _headers file you can put in public/ so it lands at the root of the build:

/*
  Content-Security-Policy: frame-ancestors 'none'
  X-Frame-Options: DENY
  X-Content-Type-Options: nosniff
  Referrer-Policy: strict-origin-when-cross-origin

The last two lines are the report's other cheap wins: nosniff stops the browser guessing file types (MDN), and a Referrer-Policy keeps full page addresses from leaking to other sites (MDN).

A full CSP that limits scripts needs more care, because a wrong policy blocks your own Supabase calls or fonts. Ship it first as Content-Security-Policy-Report-Only, which reports violations without blocking anything (MDN), use the app for a day, fix what the console reports, then enforce it. One catch: frame-ancestors doesn't work in a <meta> tag, so clickjacking protection always needs a real response header.

The short version

The report's own summary: "The fixes are mostly small: a few response headers, prerendering the pages that should be found, and a sitemap." In the apps we check, they're usually configuration, not a rebuild, and they're far cheaper to do before launch day than after.

If you'd rather not run each check by hand, our free Launch Check runs these same checks on any app in about a minute, with no sign-up. It only sees what a visitor sees, so for data access rules, sign-in and payments, go through the full pre-launch list in our Production-Ready Standard (32 checks in ten areas) or have someone review the code.

I wrote this with AI assistance and reviewed it myself.

Fixing "infinite recursion detected in policy" in Supabase (42P17)

Ahmed Hassan Yaseen — Tue, 20 Oct 2026 00:13:36 +0000

infinite recursion detected in policy for relation
code: 42P17

A row-level security policy on a table runs a query against the same table, or against a table whose policy queries back. To check the policy, Postgres needs the policy again, so it stops with 42P17. The fix I use: move the membership lookup into a security definer function in a schema the API does not expose, and call that function from the policy.

It turns up in Lovable, Bolt and Supabase apps. In our work, team, organisation and role models are where AI builders most often leave data open or loop.

Why it happens

A membership table checks itself. A policy on team_members asks "is this user a member of this team?" by selecting from team_members, which triggers the same policy.
Two tables point at each other. projects checks team_members, and team_members checks projects. Each policy needs the other first.
A roles table guards itself. A policy on profiles reads profiles.role to decide who is an admin.

Find the cause

Note the relation named in the error: that is the table whose policy loops.
Read every policy on that table and look for a subquery that selects from the same table.
Follow any subquery to another table and read that table's policies. A cycle of two tables loops the same way.

Fix 1: look the membership up in a security definer function

Create a private schema that is not listed under Exposed schemas in the API settings.
Create the function as security definer with an empty search_path, and schema-qualify every name inside it.
Replace the subquery in the policy with a call to the function.

create schema if not exists private;

create or replace function private.is_team_member(team uuid)
returns boolean
language sql
security definer
set search_path = ''
stable
as $$
  select exists (
    select 1 from public.team_members m
    where m.team_id = team and m.user_id = (select auth.uid())
  );
$$;

drop policy if exists "Members can read their team" on public.team_members;
create policy "Members can read their team"
on public.team_members for select
to authenticated
using ( private.is_team_member(team_id) );

Fix 2: keep admin flags out of a table users can edit

Store roles in a separate table that only the server writes, or in app_metadata on the user, which users cannot change.
Read the role through the same kind of function, never from a column the user can update.

Check the fix worked

Run the failing query again as a signed-in member: it returns rows.
Run it as a user who is not a member: it returns no rows, without errors.
Confirm the private schema is not in the API's exposed schemas, so the function cannot be called directly.

Stop it coming back

Draw which policy reads which table before you write them. Any cycle will loop.
Put every cross-table check behind one small function per question (is member, is admin).

Quick answers

Is a security definer function safe? Yes, when it lives in a schema the API does not expose, sets an empty search path, qualifies every name and returns only a yes or no. It runs as its owner, so keep it small.

Why not just disable RLS on the membership table? Then anyone with your publishable key can list every team and its members. The function keeps the table protected.

Source: Supabase: Row Level Security (security definer functions).

I first published this fix on our site: Fix "infinite recursion detected in policy for relation" in Supabase. For the gaps anyone can see from outside your live app (exposed keys, security headers, what Google reads), run the free Launch Check.

I wrote this with AI assistance and reviewed it myself.

DEV Community: Ahmed Hassan Yaseen

Supabase Realtime not firing? 7 checks when postgres_changes sends nothing

First, a working baseline

1. Is the table in the supabase_realtime publication?

2. Is Row Level Security quietly hiding the row?

3. Tables outside public need a grant

4. Check the subscription itself, character by character

5. Stale subscriptions in React and Next.js

6. Writing straight after SUBSCRIBED

7. Events arrive, but payload.old is empty

Still nothing?

Vite env variable undefined in production? Set VITE_ before the build

Why it happens

Find the cause

Fix 1: set the variables before building

Fix 2: move secrets to the server

Check the fix worked

Stop it coming back

Quick answers

Supabase Storage upload fails with "new row violates row-level security policy"? Here's the fix

Why it happens

Find the cause

Fix 1: let users upload into their own folder

Fix 2: allow overwrites only where needed

Check the fix worked

Stop it coming back

Quick answers

How much does it cost to fix a Lovable or Base44 app?

The short version

It depends on the app, so look first

A worked example: five findings, priced

What drives the cost

When a rebuild is cheaper than fixing

How to get your own number

What "production-ready" means for an AI-built app, in 32 checks

The definition in one sentence

Ten areas, one check from each

Why "pass or fail" wording matters

How to use it

Where to start

Stripe webhook "No signatures found matching the expected signature"? Here's the fix

Why it happens

Find the cause

Fix 1: verify the raw body in a Supabase Edge Function

Fix 2: match secrets to environments

Check the fix worked

Stop it coming back

Quick answers

Is the Supabase anon key safe in your frontend? What actually protects your data

Which key is in your JavaScript?

What the public key can do depends on your policies

Check 1: is RLS on for every table?

Check 2: do your policies limit rows to their owner?

Check 3: is a secret key anywhere it shouldn't be?

The short version

Supabase Edge Function blocked by CORS policy? Here's the fix

Why it happens

Find the cause

Fix 1: use the SDK's headers and answer the preflight

Fix 2: narrow the allowed origin before launch

Check the fix worked

Stop it coming back

Quick answers

Google sign-in fails with redirect_uri_mismatch on Supabase? Here's the fix

Why it happens

Find the cause

Fix 1: correct the Google Cloud client

Fix 2: allow the page users come back to

Fix 3: open sign-in to everyone

Check the fix worked

Stop it coming back

Quick answers

Supabase confirmation or reset email opens localhost:3000? Here's the fix

Why it happens

Find the cause

Fix 1: set the Site URL and the allow list

Fix 2: pass the redirect address from the app

Fix 3: check customised email templates

Check the fix worked

Stop it coming back

1. Is the table in the `supabase_realtime` publication?

3. Tables outside `public` need a grant

6. Writing straight after `SUBSCRIBED`

7. Events arrive, but `payload.old` is empty