DEV Community: Samrat Patel

Supabase Auth in Production: Redirects, Email and Sessions

Samrat Patel — Sat, 14 Nov 2026 10:24:02 +0000

Most Supabase Auth problems in production come from configuration rather than code: a Site URL still pointing at localhost, a redirect allow list that does not include your domain, a built-in email service that only delivers to your own team, and session settings nobody has opened. Each one takes minutes to fix once you know which is which.

This guide is for founders and small teams taking a Supabase app live, including apps generated with Lovable, Bolt or Cursor, where sign-in worked perfectly on a laptop and fails for the first real user. It covers redirects, confirmation emails, OAuth providers and sessions, and names the setting to change in each case.

Key takeaways

Site URL is the default destination for every auth email. It ships as http://localhost:3000 and has to be changed to your production address.
The built-in email service is for testing. It refuses addresses outside your organisation and sends about two messages an hour.
"Token has expired or is invalid" is often an email scanner opening the one-time link before your user does.
OAuth needs two settings to agree: the provider's authorised redirect URI and your Supabase redirect allow list.
Sessions never end by default. Inactivity timeouts, time-boxing and single-session enforcement are opt-in and only on paid plans.

Why does Supabase Auth break in production?

Because a new project ships with development defaults and nothing warns you they are still in place. The authentication code generated for you is usually fine. The environment around it is not.

These are the failures we see most often when a Supabase app meets its first real users, and where each one is fixed.

Symptom	Usual cause	Where to fix it
Confirmation link opens localhost	Site URL never changed	URL configuration
Redirect lands on the wrong page	`redirectTo` not on the allow list	URL configuration
Only your own team gets emails	Built-in email service still in use	SMTP settings
"Token has expired or is invalid"	A scanner opened the link first	Email template
Google returns a redirect URI error	Callback URL missing in the provider	Google Cloud console
Users signed out at random	Two clients refreshing one session	Client setup

Signing a user in is a separate job from deciding what they can read. Our guide to writing row-level security policies covers the half of this that lives in the database, and it is the half that leaks data when it is missing.

How do you fix the Site URL and redirect URLs?

Set Site URL to your production address, then add every other legitimate destination to the redirect allow list. Supabase's documentation states that Site URL defaults to http://localhost:3000 and that this setting is critical for email confirmations and password resets (Supabase redirect URL documentation).

The two settings do different jobs. Site URL is the fallback destination when your code does not pass a redirectTo value, and it is what email templates fall back to. The allow list is the set of addresses Supabase agrees to send a user to when your code does pass one.

When authentication fails, the user is still sent to the redirect URL, with the failure described in the URL fragment. Reading error_code and error_description on that page turns "it bounced me back to the login screen" into a message you can act on.

Preview deployments and wildcards

Preview URLs change on every deploy, so the allow list accepts wildcard patterns, where . and / count as separators. For a Vercel project, Supabase suggests keeping Site URL on the production domain and adding entries such as http://localhost:3000/** and https://*-your-team.vercel.app/**.

Keep the globstar for development and preview environments only. The same documentation recommends an exact path for the production redirect, which also keeps the allow list readable a year from now.

Why don't confirmation emails arrive?

Because the project is almost certainly still using Supabase's built-in email service. It only delivers to members of your organisation, and Supabase describes it as best-effort, not intended for production, currently limited to two messages per hour; other addresses fail with "Email address not authorized" (Supabase custom SMTP documentation).

That is why sign-up works for the founder and nobody else. Your address is on the team, so your own test passes.

	Built-in email service	Custom SMTP
Who can receive mail	Organisation members only	Anyone
Throughput	About 2 messages per hour	30 per hour, adjustable
Delivery guarantee	Best effort, no SLA	Your provider's
Sender address	Supabase's	Your own domain
Intended for	Demos and template testing	Production

Switching to custom SMTP

Any provider that speaks SMTP works, and Supabase names Resend, AWS SES, Postmark, Twilio SendGrid, ZeptoMail and Brevo among them. Once it is enabled, delivery opens up to real addresses with a starting limit of 30 messages per hour, which you raise in the rate-limit settings as your sending domain earns a reputation.

Sending is not the same as arriving. A password reset from a brand-new domain with no authentication records gets filtered no matter how well the template is written, and the DNS side of that is covered in our walkthrough of SPF, DKIM and DMARC for app email.

Why do confirmation links say the token expired?

Usually because something opened the link before your user did. Corporate mail security, including Safe Links in Microsoft Defender for Office 365, prefetches URLs in incoming messages, which consumes a single-use confirmation link and leaves the real click with "Token has expired or is invalid" (Supabase email template documentation).

Three fixes, in the order we usually try them:

Send a code instead of a link. Put {{ .Token }} in the template, ask the user to type the six digits, and verify them with verifyOtp. A scanner has nothing to consume.
Add a confirmation page. Link to a page on your own site that carries the confirmation URL as a parameter, and make the user press a button there.
Verify on your server. Point the template at your own endpoint with the token hash, exchange it for a session server-side, then redirect the user into the app.

The third option is the one to reach for in a server-rendered app, because the default link returns the session in a URL fragment that your server never sees. The template link looks like this:

<a href="{{ .SiteURL }}/auth/confirm?token_hash={{ .TokenHash }}&type=email">
  Confirm your email address
</a>

And the route behind it exchanges the hash for a session:

const { data, error } = await supabase.auth.verifyOtp({
  token_hash,
  type: 'email',
})

One more setting worth checking in your email provider: click tracking rewrites every link in a message, which breaks auth links in particular. Turn it off for transactional mail.

What does OAuth need in production?

Two sets of configuration that have to agree with each other. In the provider's console your application's domain goes in the authorised JavaScript origins and your Supabase project's callback URL goes in the authorised redirect URIs; in Supabase, whatever your code passes as redirectTo has to be on the allow list (Supabase guide to Sign in with Google).

Two details catch teams out at launch.

The consent screen shows your project reference unless you set a custom domain. Supabase suggests something like auth.example.com for an app on example.com, and points out that the default makes a phishing page harder for users to spot.
Provider tokens are not stored or refreshed for you. If your product calls Google or Slack APIs on a user's behalf, keeping those tokens alive is your job, on a server you control.

Server-rendered apps also need a callback route. The PKCE flow, which is the exchange used when the session has to be created on a server rather than in the browser, returns a code that your route swaps for a session before the user lands on a page.

How long do Supabase sessions last?

By default, until the user signs out, on as many devices as they like. The access token is a JWT that expires after an hour by default, while the refresh token behind it never expires but can only be used once (Supabase session documentation).

That single-use rule has a ten-second reuse window, which exists so a server and a browser can hand the same token around without ending the session. Outside that window, a reused token is treated as a compromised session and every refresh token for it is revoked.

This is behind most reports of users being logged out for no reason. The usual cause is two clients refreshing the same session at once, which is easy to do when a server-rendered app also creates a browser client that manages its own refresh.

When should you shorten a session?

When a customer's security review, an auditor or a shared-device workflow asks for it. Inactivity timeouts, time-boxed sessions and single-session-per-user are configurable on Pro plans and above, and they take effect at the next refresh rather than immediately. If a buyer's security questionnaire started this conversation, our broader guide to sessions, roles and SSO in a SaaS product covers what they usually ask for next.

Two numbers matter when you set them. The effective session length is your timeout plus the access token lifetime, because the check happens when the token is refreshed. And Supabase advises against access token lifetimes under five minutes, since clock skew on user devices produces failures that are painful to debug.

Common mistakes

Updating Site URL but leaving the old preview domain as the only entry on the allow list.
Launching on the built-in email service and reading "Email address not authorized" as a bug in the sign-up form.
Leaving click tracking on for the provider that sends your auth email.
Testing sign-in only in the browser profile where you are already signed in, which hides a broken redirect.
Treating a successful login as access control. The database decides what that user can read.

Frequently asked questions

Why does my magic link still redirect to localhost?

Either Site URL is still set to the development address, or the template uses {{ .SiteURL }} while your code passes a redirectTo value. Switching the template to {{ .RedirectTo }} fixes the second case, and both need the destination on the allow list.

Do I need custom SMTP if I am on a paid plan?

Yes. The restriction belongs to the built-in email service rather than to the plan, so a Pro project still cannot email addresses outside the organisation until SMTP is configured. Treat it as a launch requirement alongside a custom domain.

Can I keep users signed in for 30 days?

That is already the default behaviour, since sessions last until sign-out unless you configure a timeout. If you want exactly 30 days, set a time-box of 30 days on a Pro plan and leave the access token lifetime at an hour.

Why is the browser signed in while my server routes see an anonymous user?

Because the session lives in browser storage, where server code cannot read it. Server-rendered apps need the session in cookies, which is what Supabase's server-side helpers do, plus a callback route that completes the code exchange before rendering.

Before the first real sign-up

Work through the list in order: Site URL and the allow list, custom SMTP, an email template that survives link scanners, provider callback URLs, and a session policy you have chosen on purpose. None of it is difficult, and all of it stays invisible until a stranger tries to sign in. If the app also behaves differently on its live domain than in preview, our list of nine gaps between a preview and a published app covers the rest.

If you would rather hand the login, email and session setup to senior engineers, AlgoSmiths works on fixed-price projects with a working demo every week. Our SaaS product engineering work is where auth, billing and onboarding get built together.

Originally published on the AlgoSmiths blog. AlgoSmiths builds web, mobile and AI products on fixed-price contracts, and takes apps built with Lovable, Bolt or Cursor to production. See our services.

Lovable Cloud to Supabase Migration: A Step-by-Step Guide

Samrat Patel — Thu, 05 Nov 2026 17:53:57 +0000

To migrate a Lovable Cloud app to your own Supabase project, create a new Supabase project, export the database from Lovable, restore it with pg_restore, then move the sign-in settings, storage files, secrets and Edge Functions and point the app at the new backend. Lovable cannot hand you its Cloud project, so the move is a copy followed by a switch.

This guide is for founders who built on Lovable Cloud and want the database, users and files in an account they control, and for the developers they hire to do it. It lists the steps in order, with a check after each one and a plan for the final switch. If the code is not in GitHub yet, start with our guide to exporting your Lovable app to GitHub.

Key takeaways

Lovable Cloud runs on a Supabase project that Lovable manages. It does not appear in your own Supabase dashboard, and you cannot link it to your account.
The path is a new Supabase project, a copy of the database and the files, and a change to the app's connection settings.
The database export includes user accounts and password hashes, so people keep their passwords. Sessions end, and files, secrets, sign-in provider settings and connectors move by hand.
Keep the old backend running until the new one passes every check. Delete nothing in Lovable until you hold verified copies.

Why can't you connect your own Supabase to a Lovable Cloud app?

Because the Supabase project behind Cloud belongs to Lovable. Lovable's documentation describes Cloud as a built-in backend on Supabase's open-source foundation that Lovable manages for you. Supabase's support article spells out the effects: the project is not owned by your Supabase account, so it never shows up in your dashboard. You get no SQL editor, no external database URL and no service role or API keys, and once Cloud is enabled the project cannot be switched to an external Supabase connection.

Lovable's own guidance for leaving Cloud is a manual move. You export the database, restore it into a Supabase project you own, move the storage files and the code, and set up authentication, secrets and external services again at the destination.

What moves with the export and what you move by hand?

The database export carries the tables, the data, the user accounts and the password hashes. Everything else needs its own step.

Part of your app	How it travels	What you do
Tables, records, user accounts, password hashes	Database export	Restore with `pg_restore`
Schema and policies	Migration files in the repository	Apply them in order
Storage files	Not in the export	Download, then upload to matching buckets
Edge Function code	Repository, `supabase/functions/`	Deploy with the Supabase CLI
Secrets, sign-in provider settings, API keys	Not exported	Set them again
App connectors and AI features	Not exported	Replace with your own accounts

What do you prepare before you start?

Git sync turned on, so the repository holds the current code and the migration files.
A Supabase account, and a plan for who pays for the new project.
PostgreSQL client tools built with zstd support. A pg_restore without it can list the export but cannot restore the data.
A list of every place the app uses connectors, AI features or scheduled jobs.

How do you migrate Lovable Cloud to Supabase step by step?

Keep the live app on the built-in backend until the new backend is complete. Point the app at the new backend at the final switch. These steps follow Lovable's guide to moving the backend, with the checks we run on top.

Step 1: Create the Supabase project

In the Supabase dashboard choose New project. Set a name, a strong database password and a region close to your users, then wait for it to finish. Save the project ID, the project URL and the public (anon) API key. You need all three in step 7.

Step 2: Rebuild the schema

Apply every migration file in timestamp order, earliest first. Supabase migrations live in supabase/migrations/ and you can paste each one into the SQL editor. Drizzle migrations live in drizzle/migrations/ and follow the order in drizzle/migrations/meta/_journal.json. For the Supabase layout the CLI does the same work:

npx supabase login
npx supabase link --project-ref your-new-project-id
npx supabase db push

supabase db push does not apply Drizzle migrations. Check the result before you move on: every table exists, and every table has the row level security policies you expect. A table with row level security switched off exposes its rows to anyone who holds the public key.

Step 3: Export and restore the data

In Lovable open More, then Database, then Manage, then Settings. Under Export project data choose Export data, then Export, then Start export. Lovable emails you when the file is ready and saves it in the project's storage, so download it from More, then Storage. Databases up to 15 GB can be exported, the file can be up to 5 GB, and you get one export every 24 hours (Lovable's backup documentation).

The file is a PostgreSQL custom-format archive with zstd compression. You cannot paste it into the SQL editor. Look inside it first:

pg_restore --list your-export.backup

Then restore into the new project, following Supabase's backup and restore guidance. Account for the managed schemas, roles and extensions already in a new project, and reconcile any seed rows your migrations inserted before you import the same rows from the export. Do not add --clean without reading what it does, because it drops the objects being restored. Run the restore on the new project first as a test, then compare row counts for your main tables against the old database.

Step 4: Reconfigure sign-in

Users keep their passwords because the hashes travel in the export. Sessions do not carry over, so everyone signs in again once. In the new project open Authentication, then Sign In / Providers, and enable each provider you use. In each OAuth console, such as Google or GitHub, change the redirect URLs to the new project URL. Our guide to Supabase auth in production lists what else to check in the auth settings before you switch.

Step 5: Copy the storage files

In Lovable download the files from each bucket under More, then Storage. In Supabase open Storage and upload them to the buckets with the same names. The bucket access policies arrive with your schema migrations, so they should already exist.

Step 6: Set secrets and deploy Edge Functions

Secrets are not exported. Add each one your functions read on the Edge Function Secrets page, or from the command line:

supabase secrets set NAME=value
supabase secrets set --env-file ./secrets.env

Deploy the function code from supabase/functions/ with npx supabase functions deploy. Then list your scheduled jobs and compare them with the schedules that exist after the restore. Recreate missing database schedules with cron.schedule, and recreate schedules that call your app with your own scheduler. Make sure the old and new backends do not run the same job at the same time.

Step 7: Test on a separate deployment

Leave the Lovable project and its repository unchanged. On a separate deployment set the three browser values to the new project: VITE_SUPABASE_URL, VITE_SUPABASE_PUBLISHABLE_KEY and VITE_SUPABASE_PROJECT_ID. The build embeds these values, so rebuild after every change. Apps built on TanStack Start need SUPABASE_URL, SUPABASE_PUBLISHABLE_KEY and SUPABASE_PROJECT_ID for the server code.

Step 8: Verify before you switch

The app loads without console errors.
You can create and read records.
A migrated account signs in with its old password.
Uploads and downloads work in storage.
Edge Functions respond, and scheduled jobs ran after their first scheduled time.
The new project has backups you have tested.

Then run our free Supabase security checker against the test deployment's public address. A fresh project with a restored database is the moment a missing policy or an open bucket appears.

How do you switch to the new backend with little downtime?

Treat the switch as a short, planned pause. Lovable's guide gives this order:

Pause writes from users, jobs, webhooks and integrations.
Request the final export. Lovable allows one export per 24 hours, so do your test export the day before.
Copy any storage files that changed since your last copy.
Restore the final export into the new project.
In the Lovable project open Code, edit .env and replace the three VITE_SUPABASE_* values with the new project's values. In supabase/config.toml set project_id to the new project ID.
Save both files. The preview and the next publish then use the new backend, and Lovable pushes the change to your repository.
Point your custom domain at the new host if you moved the frontend, and unpublish the Lovable address if you no longer want it to serve the app.

Time the export and the restore during your test run. Those two numbers set how long users wait.

When is it safe to delete the old Cloud backend?

After you hold verified copies of everything, and not before. Lovable states that removing the database deletes the backend, its backups, the app's user accounts, the files in storage and the exports saved there, and that the removal cannot be undone. Download the export and the storage files and keep them outside Lovable. Exporting code or changing a domain does not cancel your hosting or your Lovable subscription, and Cloud usage continues until you change it.

Connectors and AI features run through Lovable, so each needs a replacement that uses your own accounts. Managed OAuth with automatic token refresh is available on the built-in backend alone.

What mistakes break a Lovable Cloud migration?

Restoring with --clean and dropping objects you needed.
Moving the database and forgetting the storage files.
Leaving the old redirect URLs in the OAuth consoles, so sign-in fails on the new project.
Pointing production at the new backend before a separate deployment passed the checks.
Removing the Cloud database before the downloaded export restores without errors, which deletes the export too.

Frequently asked questions

Do users keep their passwords after the migration?

Yes. The export includes user accounts and password hashes, so a restored account signs in with the same password. Sessions do not carry over, so signed-in users sign in once more. If the destination cannot restore accounts, offer a password reset flow instead.

Can I paste the export into the Supabase SQL editor?

No. The export is a compressed PostgreSQL archive, not SQL text. Restore it with pg_restore from a build that supports zstd.

Do my AI features and connectors move?

No. They run through Lovable, so you replace them with your own provider accounts and integrations at the destination. Search the code for connector and AI calls before you switch.

Can I point the same Lovable project at my new Supabase project?

Lovable's guide does this by editing .env and supabase/config.toml in the Code view. Supabase's support article says a Cloud project cannot be switched to an external Supabase connection. Because the two sources describe different routes, test the change on a separate deployment and check Lovable's current documentation before you make it on the live project.

Moving without breaking the live app

The safe order is to build the new backend in full, test it on a separate deployment, then switch in one short pause and keep the old backend until the checks pass. If you want engineers to run the move and the checks for you, talk to us about our fixed-price Lovable app rescue.

Securing Supabase Storage Buckets: Private Files and Signed URLs

Samrat Patel — Sun, 01 Nov 2026 12:43:16 +0000

Every Supabase Storage bucket starts out private, and switching one to public hands every file inside it to anyone who has the URL. Securing Supabase Storage comes down to three decisions: which buckets are public, what policies you write on the storage.objects table, and how long your signed URLs stay valid.

This guide is for founders and small teams running a Supabase app, including apps generated with Lovable, Bolt or Cursor, where uploads work but nobody has checked who can read the files afterwards. It covers the public-or-private choice, the policies files need, how signed URLs behave once a CDN is involved, and how to test a bucket from outside your own app. If your database tables are the open question rather than your files, start with our walkthrough of finding and closing row-level security gaps.

Key takeaways

Buckets are private by default. Marking one public removes read access control entirely, so a long random filename is obscurity rather than protection.
File permissions are policies on the storage.objects table, not a bucket setting. Locking down your database tables does nothing for your files.
A signed URL is a bearer token: whoever holds it can use it until it expires, and it is signed with a key you cannot rotate yourself.
A cached signed-URL response can outlive its token, so deleting the object is the only dependable way to cut off access.
One select policy covers both downloading a file and listing a folder, which is how users end up able to enumerate a bucket.

When should a bucket be public, and when private?

Public when the file is meant for everyone who can see the page it appears on, private for anything that belongs to one account. Supabase's bucket documentation is direct about what public means: access control is bypassed for retrieving and serving files, so anyone with the URL gets the file, with no session and no token.

Profile pictures, marketing images and blog media are reasonable public-bucket content. Invoices, contracts, identity documents, CSV exports and anything a customer uploaded about their own business are not.

Behaviour	Public bucket	Private bucket
Who can read a file	Anyone with the URL	Whoever a policy allows
How files are served	Permanent `/object/public/` URL	Signed URL or authenticated request
CDN caching	One cache entry per file	One cache entry per token
Cutting off access	Delete or move the file	Delete the file; expiry alone is not enough
Best for	Avatars, logos, public media	Documents, exports, per-account files

What a public bucket still protects

Uploads, deletes, moves and copies. Public changes reads only, so your insert and delete policies still run, and a public bucket with no insert policy still rejects uploads from the browser.

That split catches teams out in both directions. Making a bucket public does not open it for writes, and making it private later does not secure URLs that are already in circulation.

Why a random filename is not access control

Public object URLs leak the way all URLs leak: into screenshots, support tickets, referrer headers, shared documents and the occasional search index. Once one is out, the file is out, and the only remedy is to move or delete it.

The useful question for each bucket is what happens if one of its URLs ends up in a public post. If the answer is "nothing much", public is fine. If you are also still deciding where files should live and what to check on the way in, our guide to secure file uploads, limits and storage costs covers the upload side of the same problem.

How do Supabase Storage policies work?

Every file has a row in the storage.objects table, and Storage checks row-level security policies on that table for each operation. Supabase's Storage access control guide notes that uploads are refused outright until a policy exists, so the usual cause of a failing upload is a missing policy rather than a bucket setting.

Two columns do most of the work. bucket_id scopes a policy to one bucket, and name holds the object's full path. The helper function storage.foldername(name) returns that path as an array, so element one is the top-level folder.

The convention that holds up is one folder per user, named with their user id, with the path chosen by your code rather than by the browser.

create policy "Users upload into their own folder"
on storage.objects for insert to authenticated
with check (
  bucket_id = 'documents'
  and (storage.foldername(name))[1] = (select auth.uid()::text)
);

create policy "Users read their own files"
on storage.objects for select to authenticated
using (
  bucket_id = 'documents'
  and (storage.foldername(name))[1] = (select auth.uid()::text)
);

Both clauses matter. with check decides what may be written, and using decides which existing rows may be read or changed, which is why an upload rule and a download rule are two separate statements.

Which policies does each operation need?

Upload: an insert policy on storage.objects.
Overwrite with upsert: insert plus select and update.
Download from a private bucket, or sign a URL: select.
Delete: delete, scoped the same way as the read rule.

Write them one per operation rather than as a single for all policy. A catch-all rule hides which clause was meant to govern uploads and which was meant to govern reads, and it is the first thing to get too loose when someone asks an AI builder to fix a failing request.

Stop users from listing the whole bucket

One SQL privilege is used by more than one Storage action: downloading an object and listing a folder both go through select. A read policy written for downloads therefore also lets the client enumerate every path it matches.

Supabase provides operation-aware helpers for this, so a listing rule can be narrower than a download rule.

create policy "Users list only their own objects"
on storage.objects for select to authenticated
using (
  storage.allow_only_operation('object.list')
  and owner_id = (select auth.uid()::text)
);

This matters most where the filenames are themselves information. A list of paths like exports/acme-corp-q1.csv tells a competitor who your customers are, even if every download is refused.

How long should a signed URL last?

Long enough for the browser to fetch the file and no longer, which usually means seconds or minutes. A signed URL is a temporary address that authorises access to one object, and createSignedUrl takes its lifetime in seconds.

const { data, error } = await supabase.storage
  .from('documents')
  .createSignedUrl(`${userId}/contract.pdf`, 60)

Sixty seconds is plenty for an image the page renders on load. A download link a user clicks from an email needs minutes, not hours. A document left open all afternoon needs a fresh URL on refresh rather than a longer expiry.

Keep signed URLs out of logs, analytics events and anything that forwards a full URL to a third party. They are credentials in URL form.

Expiry is not revocation

Storage signs these URLs with a dedicated internal key, separate from your Auth JWT signing key. Supabase's documentation on serving assets from Storage states that rotating, disabling or switching auth keys does not affect URLs that are already signed, and that revoking them means contacting Supabase support.

Treat the object, not the token, as the thing you control. If a file has to stop being reachable now, delete it or move it to a new path.

Signed URLs and the CDN cache

Smart CDN caching is enabled from the Pro plan up, and it treats every unique ?token= value as its own cache key. Two consequences follow, both set out in Supabase's Smart CDN guide.

A new signed URL on every page view means a cache miss on every page view, with the origin serving everything. Re-using one URL for the life of its token is what makes caching work at all.

And a cached response can keep being served for a URL whose token has already expired, because cache duration and token expiry are independent. Deleting the object invalidates every cached entry for it, though that change can take up to a minute to propagate.

So if a file has no real per-account restriction, a public bucket caches better and removes the signing work altogether. Choose private because the content needs it, not by reflex.

Supabase Storage security settings to check before launch

Six settings account for most of the distance between a prototype and a bucket you would let strangers upload to.

Bucket visibility. Open the Storage dashboard and read the public flag on every bucket, including the ones an AI builder created for you.
Global file size limit. Free projects cap a single file at 50 MB, while Pro and Team allow up to 500 GB, per the Storage limits documentation. Set the global ceiling to the largest file your product genuinely accepts.
Per-bucket restrictions. Give each bucket a smaller size limit and an allowed MIME type list, so a misconfigured client cannot get past the checks in your API.
Path convention. Generate keys on the server under the owner's user id, and keep customer names out of paths, since every path shows up in logs.
Service key placement. The service key bypasses storage policies completely. It belongs on a server you control, never in front-end code.
Image transformations. Available on Pro and above, and billable per use. Switch the feature off if you are not using it.

How do you test a bucket from outside your app?

Call the Storage API directly with your publishable key, because your own front end is the one client that behaves. Two checks find most real problems.

First, open a public object URL in a private window while signed out. If the file loads, that bucket is public, whatever your interface suggests.

Second, ask the API to list a bucket with no user signed in:

curl -X POST "https://YOUR_PROJECT_REF.supabase.co/storage/v1/object/list/documents" \
  -H "apikey: YOUR_PUBLISHABLE_KEY" \
  -H "Authorization: Bearer YOUR_PUBLISHABLE_KEY" \
  -H "Content-Type: application/json" \
  -d '{"prefix":"","limit":100}'

An empty array or an error means the bucket is closed to signed-out visitors. A list of filenames means anyone on the internet can read your storage layout. Then repeat the request with a second account's token, asking for the first account's folder, which is the test that catches a policy matching on the wrong column.

Storage is one item on a longer pre-launch list, and our launch checklist for AI-built apps covers the rest.

Common mistakes with Supabase Storage

Treating a database backup as a backup of your files. Database backups do not include stored objects, as the gaps a database backup leaves explains.
Making a bucket public to fix a broken image, then never changing it back.
Letting the browser choose the storage path, so a user can write into someone else's folder.
Signing URLs that last a week because a one-minute URL expired during testing.
Assuming an expired token makes a file unreachable, when a cached response may still be served.
Writing one broad select policy, then finding the client can list every object it matches.
Reaching for the service key on the client to make permission errors go away.

Frequently asked questions

Is a public bucket safe for profile pictures?

Usually, if the picture is already visible to other users of your product. The risk is not the image but what sits beside it in the same bucket, so keep public buckets for genuinely public content and never mix documents in. Uploads and deletes still need policies either way.

Can I make a public bucket private later?

Yes, and the files stop being reachable through their public URLs as soon as you do. Anything that embedded those URLs needs to switch to signed URLs first, otherwise images in your own app break. Copies of those links held elsewhere also stop working, which is the point.

Do I need storage policies if every upload goes through my backend?

You need them unless no client ever holds a publishable key with storage access. While the Storage API is reachable with that key, the browser route exists whether or not your app uses it, and a feature added later by an AI builder may well start using it.

Why does my upload fail with a row-level security error?

Almost always a missing or mismatched insert policy. Check the bucket name in the policy, confirm the path your code generates starts with the folder the policy expects, and confirm the request is authenticated, because a policy limited to the authenticated role never matches an anonymous call.

Does signing URLs slow the app down?

Each signed URL is an API call, which is fine for one document and expensive for a gallery of 200 thumbnails. Sign in batches with createSignedUrls, re-use each URL for the life of its token, and keep genuinely public assets in a public bucket.

Before your first real upload

Go bucket by bucket and decide whether the content is public or per-account. Write the policies for the private ones, generate paths on the server, keep expiry short, and remember that deleting the object is the only reliable kill switch. Then run the list request against your own project and see what a stranger sees.

If you would rather have senior engineers close these gaps for you, AlgoSmiths works on fixed-price projects with a working demo every week. Our backend and API engineering work is where storage, policies and the services around them get built.

Supabase Row Level Security: Fix Data Leaks in Lovable Apps

Samrat Patel — Sat, 24 Oct 2026 08:23:37 +0000

Supabase Row Level Security (RLS) is a PostgreSQL feature that decides, row by row, which records each request is allowed to read or change. In a Lovable or Bolt app the browser talks straight to your database over a public API, so RLS is usually the only thing standing between a stranger and your users' data. With it switched off, every row in the table is readable. If it is your sign-in flow that is broken instead, our guide to redirects, auth emails and sessions covers that side.

This guide is for founders and small teams who built on Supabase with an AI builder and need to know whether their tables are exposed. It covers what RLS does, why generated apps leak, how to test your own tables in about ten minutes, and working policies for user-owned rows, team rows and admin access. Data access is also the first item on our pre-launch checklist for AI-built apps.

Key takeaways

RLS is off by default on new tables, and an unprotected table in an exposed schema can be read or written by anyone holding your public API key.
Grants and policies are separate checks. Adding a policy does not remove privileges already granted to the anon and authenticated roles.
You can test your own app in ten minutes with two accounts, a logged-out browser window and one curl command.
Most tables need four policies, one each for select, insert, update and delete, rather than a single catch-all rule.
Index every column your policies filter on. In Supabase's own measurements that took a query on a 100,000-row table from 171ms to under 0.1ms.

What does Supabase Row Level Security actually do?

RLS adds an invisible WHERE clause to every query that touches a table. You write the clause once as a policy, and PostgreSQL applies it to every request, whether it comes from your app, a REST call or a database client.

A policy like this one on a projects table lets signed-in users see only their own rows:

create policy "Owners read their own projects"
on public.projects for select
to authenticated
using ( (select auth.uid()) = owner_id );

The using clause decides which existing rows a statement can touch. A separate with check clause decides what a new or updated row may look like, which is what stops a user inserting a row that belongs to someone else.

Once RLS is enabled, the default is deny. PostgreSQL's row security documentation explains that with row security on and no policy present, no rows are visible or modifiable. Policies then open access back up: permissive policies combine with OR, restrictive policies with AND.

This is authorization, not authentication. Supabase Auth proves who the user is; RLS decides what that user may reach. Our guide to auth and access control for SaaS products covers the wider picture.

Grants and policies are two different checks

PostgreSQL checks table grants first and policies second, and this is where most Supabase apps go wrong. Supabase's Row Level Security documentation notes that on existing projects a new table in public starts with select, insert, update and delete already granted to anon, authenticated and service_role, and that adding policies does not take those grants back.

Securing a table is therefore three statements, not one:

alter table public.projects enable row level security;
revoke all on table public.projects from anon, authenticated;
grant select, insert, update, delete
  on table public.projects to authenticated;

If a request fails that your policy should allow, check the grant before you rewrite the policy. A missing grant raises error 42501 before any policy runs.

Which role is your request running as?

Every API key resolves to a PostgreSQL role, and your policies match on that role. Supabase's API keys guide sets out the mapping and notes that the legacy anon and service_role keys are being deprecated by the end of 2026 in favour of publishable and secret keys.

Key in the request	User signed in	PostgreSQL role	Effect of RLS
Publishable or anon	No	`anon`	Policies apply
Publishable or anon	Yes	`authenticated`	Policies apply, `auth.uid()` set
Secret or service_role	Not applicable	`service_role`	Bypassed entirely

The publishable key is meant to be public. It ships inside your JavaScript bundle, so anyone can read it out of the page source in seconds. It is not a password, and treating it as one is the misunderstanding behind most Supabase data leaks.

Why do Lovable and Bolt apps leak data by default?

Because the generated front end treats the screen as the access control, and nobody told the database. Your dashboard renders only your own projects, but the API endpoint behind it will hand over every row to anyone who asks with the public key.

Nothing on screen tells you this is happening. The app looks correct because you are the only user, and generated code rarely includes the migration that enables RLS, revokes the grants and writes the policies.

This has already caused real incidents. CVE-2025-48757 describes insufficient row-level security policies in Lovable through 15 April 2025 that allowed unauthenticated attackers to read or write arbitrary database tables of generated sites, scored 9.3 and rated critical by MITRE. The vendor disputes the framing, on the grounds that each customer accepts responsibility for their own application's data. Either way, the policies are yours to write and yours to verify.

How do you test your tables with the anon key?

Test from outside your app, because your app is the one client that behaves. Two checks find almost every real leak: a second account in a private window, and a direct request to the REST API.

The two-account browser test

Create two ordinary accounts. Sign in as the first and add some data. Sign in as the second in a private window and try to reach the first account's records by changing the ID in the URL. Then sign out completely and reload. If you can see or change anything that is not meant to be public, your policies are missing or too loose. Do not run this test with your admin account, which usually carries a role your policies treat differently.

The curl test that skips your app entirely

This is the test that matters, because an attacker will never use your interface. Take the project URL and publishable key out of your front-end bundle and ask the REST API directly:

curl "https://YOUR_PROJECT_REF.supabase.co/rest/v1/projects?select=*" \
  -H "apikey: YOUR_PUBLISHABLE_KEY" \
  -H "Authorization: Bearer YOUR_PUBLISHABLE_KEY"

No signed-in user is involved, so the request runs as anon. An empty array or a permission error means the table is closed to signed-out visitors. Rows coming back means anyone on the internet can read that table. Repeat it for every table name you can find in your code, then try a POST to the same path to check writes.

Manual checks drift, so write them down. Supabase supports pgTAP database tests, so the allow and deny cases for each table can live in supabase/tests/ and run with supabase test db. A future prompt that regenerates your schema then cannot quietly reopen a table.

Policy examples for user-owned rows, team rows and admin access

Three ownership shapes cover most products. Write all four operations for each table: PostgreSQL does not accept several operations in one for clause, and a catch-all for all policy hides which rule was meant to cover which operation.

Rows owned by one user

The simplest case is a row that belongs to whoever is named in its owner_id column.

create policy "Owners select" on public.projects
  for select to authenticated
  using ( (select auth.uid()) = owner_id );

create policy "Owners insert" on public.projects
  for insert to authenticated
  with check ( (select auth.uid()) = owner_id );

create policy "Owners update" on public.projects
  for update to authenticated
  using ( (select auth.uid()) = owner_id )
  with check ( (select auth.uid()) = owner_id );

create policy "Owners delete" on public.projects
  for delete to authenticated
  using ( (select auth.uid()) = owner_id );

The update policy needs both clauses. using picks the rows the user may edit, and with check stops them reassigning the row to somebody else by rewriting owner_id. An update also needs a matching select policy to behave as expected.

Always name the role with to authenticated. A policy without it runs for anon as well, and auth.uid() returns null on a signed-out request, so the comparison quietly evaluates to false instead of failing loudly.

Rows shared by a team or workspace

Here membership lives in its own table, and the obvious version deadlocks. A policy on projects reads team_members to find who the project is shared with, and the policy on team_members reads projects to find the owner. PostgreSQL raises 42P17, infinite recursion detected in policy, and every query fails.

Break the cycle with a security definer function, which reads the membership table as its owner so the second policy never runs:

create schema if not exists private;

create function private.my_team_ids()
returns setof uuid
language sql
security definer
set search_path = ''
stable
as $$
  select team_id from public.team_members
  where user_id = (select auth.uid())
$$;

revoke execute on function private.my_team_ids() from public;
grant usage on schema private to authenticated;
grant execute on function private.my_team_ids() to authenticated;

create policy "Team members select" on public.projects
  for select to authenticated
  using ( team_id in (select private.my_team_ids()) );

Two details are not optional. Set search_path = '' and schema-qualify every name inside the function, otherwise a caller can point an unqualified name at an object they control and have it run with the function owner's privileges. And keep the function in a schema that is not exposed through the Data API, or it becomes callable over the API with those same privileges.

How far a shared-table pattern takes you depends on your tenancy model. Our write-up on choosing a multi-tenant SaaS architecture compares row-level isolation like this with schema-per-tenant and database-per-tenant setups.

Admin and staff access

Give admins their own extra policy rather than loosening the owner policy. Permissive policies combine with OR, so an additional policy widens access without weakening the rule that protects ordinary users.

create policy "Staff read everything" on public.projects
  for select to authenticated
  using ( (select private.is_staff()) );

Source the admin flag from somewhere the user cannot edit. Supabase's raw_user_meta_data is writable by the user through the auth API, so a policy built on it lets an attacker promote themselves. Use a staff table read through a security definer function, or raw_app_meta_data, which users cannot change. A JWT is also a snapshot: removing someone's role does not change auth.jwt() until their token refreshes.

Where RLS does not protect you

RLS covers tables reached with a publishable key. Three paths go around it, and each needs its own control.

The secret or service_role key. It holds the BYPASSRLS attribute, so no policy applies to it. One secret key in front-end code makes every policy you wrote irrelevant. Our guide to handling API keys and environment variables covers where each kind of key belongs and how to rotate one that has leaked.
Views. PostgreSQL creates views as security definer by default, so a view over a protected table hands out the rows its policies were meant to withhold. On PostgreSQL 15 and later, create views with security_invoker = true.
Storage. Files sit behind separate policies on the storage schema. A locked-down table next to a public bucket of user uploads is still a leak. Our guide to securing your storage buckets covers the storage policies and signed URLs.

Does RLS slow your app down?

Not if you index the columns your policies filter on, and badly if you do not. A policy is evaluated per candidate row, so an unindexed filter column turns a simple read into a sequential scan of the whole table.

Supabase's published RLS performance tests, run against a 100,000-row table, show how large the difference is.

Change	Before	After
Index added on the policy's `user_id` column	171ms	under 0.1ms
`auth.uid()` wrapped as `(select auth.uid())`	179ms	9ms
Table join moved into a `security definer` function	11,000ms	7ms
Role named with `to authenticated`, anon request	170ms	under 0.1ms

Wrapping a helper call in a subselect lets the planner run it once per statement instead of once per row. It works for auth.uid(), auth.jwt() and security definer functions, as long as the result does not depend on the row being checked.

Keep the filter in your client query as well as in the policy. Calling .eq('owner_id', userId) alongside the policy gives the planner something to work with, and leaves RLS as the guarantee rather than the filter.

Common RLS mistakes

Enabling RLS and stopping there. Without policies the table is closed, the app breaks, and the usual fix reopens it to everyone.
Writing a using ( true ) policy. That is right for a genuinely public feed and wrong everywhere else, and it is what AI tools generate when asked to fix a query that returns nothing.
Omitting with check on insert and update, which lets a user create a row in, or move a row into, someone else's account.
Leaving the default grants in place after adding policies, so anon keeps an insert path nobody tested.
Testing on an empty table. Zero rows returned proves nothing until another user's row exists to be leaked.

Frequently asked questions

Is it safe to expose the Supabase anon key in my front-end code?

Yes, that is what it is for. The publishable or anon key identifies your application rather than your user, and Supabase documents it as safe to ship in web pages and mobile apps. It is only safe because RLS limits what it can reach, so the key being public and your data being public are two different things.

Do I still need RLS if everything goes through my own backend?

You need it unless the Data API is switched off entirely. As long as the REST endpoint is reachable with a publishable key, the browser route exists whether or not your app uses it. Keeping RLS on also means a feature added later through an AI builder cannot bypass your checks.

Why does my update succeed but change nothing?

Almost always a missing select policy, or a using clause that matches no rows. A using clause that filters every row out returns success with zero rows changed rather than an error. Add returning to the statement and you will see that it affected nothing.

Can I let Lovable write the policies for me?

Use it for a first draft, then verify the result yourself. Generated policies often omit the to authenticated clause, skip with check, or leave the default grants untouched. The curl test takes a minute and tells you whether the SQL did what the explanation claimed.

How long does retrofitting RLS onto a live app take?

For a small app with a handful of tables and clear ownership columns, a day or two including tests. It takes longer when rows have no owner column, when sharing rules were only ever enforced in the front end, or when views and background jobs have to be reworked too.

Getting your tables locked down

Start with the curl test, because it tells you within a minute whether you have a problem. Then go table by table: enable RLS, revoke the default grants, write four policies, index the columns those policies filter on, and save the allow and deny cases as tests. Keep the secret key on the server, and check your views and storage buckets before you call it done. If the policies check out and the live site still misbehaves, the cause is usually configuration, which our nine fixes for a Lovable app that breaks in production covers.

If you would rather have senior engineers audit the policies and close the gaps, AlgoSmiths works on fixed-price projects with a working demo every week. Our backend and API engineering work is the place to start.