Where the link comes from

Supabase builds the links in auth emails from your project's Site URL. New projects start with it set to http://localhost:3000. Three things send users there:

• The Site URL was never changed. With no other instruction, every link falls back to it.
• The app redirects to an address Supabase doesn't allow. A redirect that isn't on the Redirect URLs list is dropped, and the Site URL is used instead.
• The email template links with {{ .SiteURL }}. A customised template that uses it ignores the redirect your code passed. For redirect flows the template should use {{ .RedirectTo }}.

Work out which one you have

Hover the button in the email and read the address. Then open Authentication > URL Configuration in the Supabase dashboard and compare it with the Site URL and the Redirect URLs list. Last, look at the calls in your code to signUp, resetPasswordForEmail and signInWithOtp, and note the redirect address each one passes.

Fix the project settings

Set the Site URL to the address your users actually use, such as https://app.example.com. Under Redirect URLs, add the exact pages your auth flows land on, for example /auth/callback and /reset-password on that domain. You can keep http://localhost:3000/** for local development, but in production the Supabase docs recommend exact paths over wildcards.

Pass the redirect from your code

When the redirect is built from the current origin, the same code works on previews and in production:

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

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

Each origin you run on still has to match an entry on the Redirect URLs list.

Update custom templates

If you edited the email templates, open Authentication > Email Templates and swap {{ .SiteURL }} for {{ .RedirectTo }} wherever the flow passes a redirect address.

Prove it's fixed

1. Sign up with an email address you haven't used before. The link should open your live site and sign you in.
2. Ask for a password reset. The link should open the reset page on your live domain.
3. If you have a preview or staging site, try once there too, so you know its pattern is allowed.

Keep it fixed

Both settings belong to each Supabase project, so add them to your launch checklist for every new one. And set up a custom sending domain for auth emails before launch, so the emails land in inboxes in the first place.

Two questions I get: you don't need to redeploy after changing the Site URL, because new emails pick it up straight away (old emails keep their old links). For a mobile app, use a deep link such as com.example.app://login-callback as the redirect and add it to the Redirect URLs list.

Source: Supabase: Redirect URLs.

This fix first appeared on our site: Supabase confirmation or reset email links to localhost. If you want a quick outside look at your live app (exposed keys, security headers, what Google can read), the free Launch Check takes about a minute.

I wrote this with AI assistance and reviewed it myself.

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.

What causes the loop

There are three common shapes:

• The membership table checks itself. The policy on team_members decides whether you are a member by selecting from team_members. That select runs the same policy, which runs the same select.
• Two tables check each other. The projects policy reads team_members, and the team_members policy reads projects. Neither can be evaluated first.
• The roles table guards itself. The profiles policy reads profiles.role to work out who is an admin.

Track it down

The relation named in the error is the table whose policy loops. Open every policy on it and look for a subquery that selects from that same table. If a subquery reads another table, open that table's policies too: two tables that reference each other loop just like one.

The fix: a security definer lookup

Move the "is this user a member?" question into a small function that runs as its owner, so it can read team_members without triggering the policy:

1. Put it in a private schema that is not listed under Exposed schemas in the API settings.
2. Declare it security definer, set search_path = '', and schema-qualify every name.
3. Have the policy call the function instead of running its own subquery.

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) );

Roles: keep them where users can't write

If the loop comes from an admin check, the bigger problem is that the role sits in a column the user can update. Store roles in a table only the server writes, or in the user's app_metadata, which users cannot change. Read them through the same kind of function.

Test it

• As a signed-in member, the query that failed now returns rows.
• As a user who isn't a member, it returns no rows and no error.
• The private schema is absent from the API's exposed schemas, so nobody can call the function directly.

Keep it from coming back

Sketch which policy reads which table before writing them, because any cycle will loop. Then give each cross-table question (is member, is admin) its own small function.

FAQ

• Is security definer safe here? Yes, if the function lives in an unexposed schema, has an empty search path, qualifies every name and returns only true or false. Keep it small, since it runs as its owner.
• Can I turn RLS off on the membership table instead? You can, but 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).

This is a cross-post of my original fix on stacksmesh.com. To check what 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.

Why this matters for AI-built apps

The State of AI-Built Apps 2026 report put numbers on it. "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." The biggest gap: "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."

A missing header breaks nothing you can see, which is why it's so easy to ship without one. And a Lovable or Vite build is a folder of static files, so no change to your React code adds these headers. They come from whatever serves the files.

Two headers close most of that gap:

• Content-Security-Policy (CSP) tells the browser which sources your page may load scripts, styles, images and network requests from. MDN's CSP guide explains it as a defence against cross-site scripting: injected code that runs as if it were your own.

• Framing protection. The CSP frame-ancestors directive controls which sites may embed your page in an iframe. MDN calls it "an effective protection against clickjacking attacks" and says that unless you need your site to be embeddable, you should set it to 'none'. X-Frame-Options: DENY is the older header that does the same job in older browsers (MDN: X-Frame-Options).

Step 1: write a starting policy

Before writing anything, open developer tools on your live site, go to the Network tab, reload and use the main features. Write down every domain the app talks to: your Supabase project, font hosts, analytics, payments, image hosts. Those go in the policy.

For a typical Vite + React app on Supabase, I start here. Replace YOUR-PROJECT with your Supabase project reference:

default-src 'self';
script-src 'self';
style-src 'self' 'unsafe-inline';
img-src 'self' data: blob: https:;
font-src 'self' data:;
connect-src 'self' https://YOUR-PROJECT.supabase.co wss://YOUR-PROJECT.supabase.co;
frame-ancestors 'none';
base-uri 'self';
form-action 'self';
object-src 'none'

What each line is doing:

• default-src 'self': anything not listed below may only come from your own domain.

• script-src 'self': scripts only from your own files. MDN warns against 'unsafe-inline' for scripts because "it defeats much of the purpose of having a CSP".

• style-src 'self' 'unsafe-inline': many UI libraries add style tags at runtime and stop working without 'unsafe-inline'. Inline styles carry far less risk than inline scripts, which this policy still blocks. If your app works without it in report-only mode, remove it.

• img-src and font-src: Vite inlines small images and fonts as data: URIs, so allow data: there. Never allow data: in script-src.

• connect-src: where fetch and WebSocket calls may go. Your Supabase API is https://<ref>.supabase.co, and Supabase Realtime connects over wss://<ref>.supabase.co/realtime/v1/websocket (Supabase: Realtime protocol). MDN notes that 'self' does not cover WebSocket schemes in every browser (MDN: connect-src), so list the wss:// host explicitly.

• frame-ancestors 'none': nobody may frame your app. If you embed your own pages, use 'self' instead.

• base-uri 'self', form-action 'self' and object-src 'none': an injected <base> tag can't change where relative URLs point, forms only submit to your own domain, and <object>/<embed> are blocked.

Then add each other domain from your Network list to the matching rule. Google Fonts, for example, needs https://fonts.googleapis.com in style-src and https://fonts.gstatic.com in font-src. Payment and analytics providers publish the domains their scripts need. Add only the hosts you actually use.

Step 2: ship it in report-only mode first

A wrong policy breaks your app, so don't enforce it on day one. The Content-Security-Policy-Report-Only header (MDN reference) exists for exactly this: in MDN's words, "The policy is not enforced, but any violations are sent to the reporting endpoint." Deploy the report-only version and use every screen for a few days with the browser console open: sign in, save data, upload, pay, and anything realtime. Each report names the rule and the blocked address. Each one is either a host you forgot or something you don't want loading at all.

On Vercel, add a headers block to vercel.json in the project root and redeploy. The /(.*) source matches every path, as in Vercel's own example. If the file already has the rewrite that serves index.html for your app routes, keep both keys in the same file. Each header value must stay on one line:

{
  "rewrites": [{ "source": "/(.*)", "destination": "/index.html" }],
  "headers": [
    {
      "source": "/(.*)",
      "headers": [
        {
          "key": "Content-Security-Policy-Report-Only",
          "value": "default-src 'self'; script-src 'self'; style-src 'self' 'unsafe-inline'; img-src 'self' data: blob: https:; font-src 'self' data:; connect-src 'self' https://YOUR-PROJECT.supabase.co wss://YOUR-PROJECT.supabase.co; frame-ancestors 'none'; base-uri 'self'; form-action 'self'; object-src 'none'"
        },
        { "key": "X-Frame-Options", "value": "DENY" }
      ]
    }
  ]
}

On Netlify, create a _headers file. It has to end up in the folder you deploy (Netlify: custom headers). In a Vite project, files in public/ are "copied to the root of the dist directory as-is" (Vite: the public directory), so put it at public/_headers, with each header on its own indented line under the path:

/*
  Content-Security-Policy-Report-Only: default-src 'self'; script-src 'self'; style-src 'self' 'unsafe-inline'; img-src 'self' data: blob: https:; font-src 'self' data:; connect-src 'self' https://YOUR-PROJECT.supabase.co wss://YOUR-PROJECT.supabase.co; frame-ancestors 'none'; base-uri 'self'; form-action 'self'; object-src 'none'
  X-Frame-Options: DENY

Netlify's docs add one limit worth knowing: custom headers aren't applied to proxied content or to URLs handled by a function or edge function, such as server-side rendered pages.

On Lovable's own hosting, put the headers in front of the app or host the build yourself. If your domain already runs through Cloudflare, a Response Header Transform Rule can set the same headers on every response. Otherwise, Lovable's Git sync keeps the code in a repository you own so you can "deploy anywhere" (Lovable: Git sync), for example with the Vercel or Netlify setup above. Either way, confirm with curl -I https://your-domain.com that the headers reach your custom domain.

Step 3: enforce it

When the console stays clean, rename the header from Content-Security-Policy-Report-Only to Content-Security-Policy and deploy again. Keep X-Frame-Options: DENY next to it for older browsers; it costs nothing.

Then test the important flows once more: sign-in, data loading, file upload, checkout and anything realtime. A quick framing test helps too: a page on another origin that loads your site in an iframe should show the frame blocked.

What if my host won't let me set headers?

MDN says you can also deliver a CSP in a <meta http-equiv="Content-Security-Policy"> tag, and that this suits "a client-side-rendered single page app which has only static resources". It has two catches. A report-only policy cannot be delivered in a <meta> element (MDN: CSP guide), and frame-ancestors is not supported in <meta> (MDN: frame-ancestors). Setting X-Frame-Options in a meta tag "has no effect" (MDN: X-Frame-Options). So a meta tag can restrict scripts and requests, but clickjacking protection needs a real response header.

Common mistakes I'd avoid

• Adding 'unsafe-inline' or 'unsafe-eval' to script-src, or a bare * anywhere, to make an error go away. That switches most of the protection off. Find the inline script and move it into a file instead.

• Forgetting the wss:// host. The browser blocks the Realtime connection.

• Setting frame-ancestors 'none' when you really do embed the app, for example inside your own marketing site. List that site's origin instead of 'none'.

• Only checking the home page. Policies break on the screens that load third-party code: payments, maps, support chat.

• Adding a new service without updating the policy. When you add analytics, chat or payments, add its domains to the policy in the same change, and keep vercel.json or public/_headers in the repository so every deploy carries the headers.

Check it from outside

Once it's live, run curl -I on your home page and on a deep link and look for content-security-policy and x-frame-options. Or run the free Launch Check on your URL: it checks exposed keys, security headers, what Google and AI assistants see, speed and accessibility, in about a minute, with no sign-up.

I wrote this with AI assistance and reviewed it myself.

How a key leaks into the bundle

1. Direct calls from React. The builder wires the provider into a component so the demo works, and the key loads with every page.

2. Public env prefixes. Vite inlines every VITE_ variable at build time, and Next.js inlines NEXT_PUBLIC_. A key stored under either is public.

3. dangerouslyAllowBrowser. OpenAI's JavaScript library only runs in a browser with this flag set, and its own docs say it exposes your secret credentials.

4. Pasted keys. A key dropped into the builder's chat or a settings file can be written into frontend code.

Diagnose before you change anything

• Run the free Launch Check against the live app. It scans the JavaScript your site sends for OpenAI, Anthropic and Gemini keys and never shows the key itself.

• In the Network tab, trigger the AI feature. Requests to api.openai.com or generativelanguage.googleapis.com coming from the browser confirm the leak.

• Search the codebase for sk-proj-, sk-ant-, AIza, dangerouslyAllowBrowser and key-holding VITE_ variables.

• Look at the provider's usage page for traffic or spend you don't recognise.

Step 1: put the call behind an Edge Function

Save the key as a secret, not as a VITE_ variable. In Lovable, that's More > Cloud > Secrets. For your own Supabase project, run supabase secrets set OPENAI_API_KEY=....

The function should accept signed-in users only, check its input, and read the key from Deno.env.get. Gemini works the same way through the generateContent endpoint, with the key in the x-goog-api-key header. The page then uses supabase.functions.invoke, and the key and provider SDK come out of the frontend entirely.

// supabase/functions/ai-reply/index.ts
// The key lives in Edge Function secrets, never in the app.
import { withSupabase } from 'npm:@supabase/server@1';

export default {
  // auth: 'user' refuses callers who are not signed in.
  // CORS and preflight requests are handled for you.
  fetch: withSupabase({ auth: 'user' }, async (req) => {
    const { prompt } = await req.json();
    if (typeof prompt !== 'string' || prompt.length > 4000) {
      return Response.json({ error: 'Invalid prompt' }, { status: 400 });
    }

    const res = await fetch('https://api.openai.com/v1/responses', {
      method: 'POST',
      headers: {
        Authorization: `Bearer ${Deno.env.get('OPENAI_API_KEY')}`,
        'Content-Type': 'application/json',
      },
      // Use any model your project has access to.
      body: JSON.stringify({ model: 'gpt-5-mini', input: prompt }),
    });
    if (!res.ok) {
      return Response.json({ error: 'AI request failed' }, { status: 502 });
    }
    return Response.json(await res.json());
  }),
};

// In the page: no key and no OpenAI SDK, just the function.
const { data, error } = await supabase.functions.invoke('ai-reply', {
  body: { prompt },
});

Step 2: rotate the leaked key

Wait until the function is live, or the replacement leaks too.

• OpenAI: new key on the project's API keys page, store it as the server secret, delete the leaked key.

• Gemini: new key in Google AI Studio (since 28 May 2026, keys created there are auth keys limited to the Gemini API by default), store it, delete the old one, and restrict any key you keep to the Gemini API.

• Deletion can't be undone, so move every function and server to the new key before you delete.

Step 3: contain the cost in the meantime

• A budget alert in the provider's billing settings tells you about unexpected spend the same day.

• A per-user request limit in the function, such as a daily count in a table, stops one account draining the budget.

• Record unfamiliar usage and its dates in case you need to take it up with the provider.

Verify

• The Launch Check finds no AI keys.

• DevTools shows the browser calling your function, not the provider.

• A signed-out call to the function is refused.

• The leaked key shows as deleted in the provider dashboard.

Prevent a repeat

Keep provider keys in server secrets only, never in a public env prefix and never with dangerouslyAllowBrowser. Ask your builder for AI features "through an Edge Function, with the key stored in Secrets" from the very first prompt. Turn on GitHub secret scanning and rerun the Launch Check after each publish.

FAQ

• Does an environment variable hide the key? Not in frontend code: VITE_ values are written into the JavaScript at build time. Only a server or Edge Function keeps them secret.

• Is a domain-restricted Gemini key enough? Not for a key that can spend money. The restriction checks the Referer header, which a script outside a browser can set to anything; Google recommends calling the Gemini API from your server.

• Is Lovable's built-in AI affected? Not by design. It uses LOVABLE_API_KEY, a secret only Edge Functions can read, with a Rotate action in Secrets. The risk is a key you add and call from the page yourself.

• Will OpenAI or Google kill a leaked key for me? Don't rely on it. Until they act, every request with your key is billed to you.

I first published this fix on stacksmesh.com, where every official source is linked. To scan your own app for exposed keys, try the free Launch Check.

I wrote this with AI assistance and reviewed it myself.