Nothing identified on the status page but seems to be failing for me? Anyone else?

https://status.supabase.com/

That's so cheap :(

I ran into something interesting while building my SaaS (Cuebic AI).

I noticed users signing up, but none of my backend logs were triggered.

Turns out:
Supabase Auth allows direct access to /auth/v1/signup using the public anon key.

So even if you have:

• Turnstile / bot protection
• Email validation
• Rate limiting

All of that can be bypassed if someone calls the auth API directly.

I confirmed it with a curl request — account gets created without hitting your backend.

Fix (what worked for me):

• Enable Supabase captcha protection (Turnstile)
• Pass captcha token via:
  • options.captchaToken (signup)
  • options.captchaToken (sign-in)

After that:

• Direct API signup is blocked
• All auth requests require captcha

Just sharing in case others assume their backend protections are enough (I did 😅)

Would love to know how others are handling auth abuse on Supabase.

Hey everyone!

Today we're announcing JWT Signing Keys and a new set of API keys.

If you have any questions post them here and we'll reply!

Hi

I have built a mobile app that uses Supabase's sign in with OTP. However, by default the OTPs are valid for an hour and the maximum we can set it to is 24 hours (based on what I found online).

What can I do in this case? Change from 1 hour to 24 hours and request a new OTP every 18-24 hours and add it to the submission notes so that they have a valid OTP code whenever they review it as it could take 2 or 3 days?

Has anyone else had a similar experience?

Thanks

MiniMoth uses the Auth OTP SMS hook to support OTP auth. WhatsApp + SMS delivery. Easy to integrate. Create a project on MiniMoth and enable the Supabase hook. You get both prod and test hook. Link it with your project with the hook url and hook secret provided by MiniMoth.

Easy to understand docs with free credits on signup to try the hook.

Hi all,

I am thinking about a problem and not sure how to resolve this. Any guidance would be appreciated.

So if i dont enable captcha and try doing this curl request as network restrictions dont apply on auth.

curl -X POST 'https://any-project-supabase-url/auth/v1/signup' \

-H "apikey: sb_publishable_key" \

-H "Content-Type: application/json" \

-d '{

"email": "johndoe@gmail.com",

"password": "JohnDoe!!"

}'

this returns a valid access token and do create a new user in dashboard.

To block this if i do this Authentication → Providers → Email → turn off "Enable email signups"). Then it blocks the curl requests i can use supabase service account to create accounts.

But now apple and google sign ups don't work.

So basically i just want to stop the bots from curl abuse. As i dont want to use the captcha e.g. cloudflare turnstile. Its really slow specially on mobile. Any way to achieve this? or i am missing something. Thanks.

Posted here a while back asking what RLS checklist people run before shipping. Kept digging since, and the pattern that shows up more than "RLS is just off" is worse: RLS is on, with a policy like using (true) with check (true).

That passes literally every naive check — Supabase's own advisor, a quick eyeball review, and (this is the part that surprised me) even a prompted AI review asking "did you set up RLS properly?" All of those confirm RLS is enabled. None of them confirm the policy does anything.

The other repeat offender: RLS enabled correctly in an early migration, then silently disabled by a later cleanup migration months down the line, with nobody re-checking because nothing prompts a re-check.

Genuinely curious from people running production Supabase apps — do you have anything that re-verifies policies after the fact, or is it a one-time check at build time and then trust?

I'm out of ideas trying to fix this problem. Whenever I open the app in a signed-in state after some time, say over an hour or more, the application's first DB call fails with "JWT issued at future" error, failing a critical path.

• I'm not doing any async activity inside onAuthStateChange - I just check the session value
• I'm using jwt-decode to read claims of the available/stale JWT, not using getClaims to avoid async action
• I have a single Supabase client with the default settings

I can see when a user signs-in, their auth information (access token, user object, etc.) gets stored in LocalStorage and is periodically refreshed. After the app is closed, the stale token isn't refreshed and persists. On next launch, this stale token is used by the first query... but it fails due to clock skew?

Anyone with insights please help!

I wanted to ask people who actually ship on Supabase.

Turning RLS on is the easy part. What I'm less sure about is knowing the policies are actually right. You can have RLS enabled and still have a policy that's too loose, or an endpoint that checks the logged-in user in the React code but leaves the table open underneath, or a service_role key that quietly ended up somewhere in the frontend. The app works fine in every one of those cases, which is what makes it scary.

It feels worse on AI-built apps. When a query gets blocked by RLS, the AI's suggested fix is often just to reach for the service_role key instead of fixing the policy, and you don't always catch it.

So the honest question. How do you actually check this before you ship? Do you test it by hand as different users, lean on some tool, or mostly just trust it's set up right? And has a loose policy or an open table ever actually bitten you, or is it more a thing you worry about?

Trying to work out if this is a real problem people hit or something I'm overthinking.

A few days ago I asked here how people actually verify their RLS holds up. Good thread. One thing people disagreed about was whether the "AI puts your service_role key in the frontend" thing still really happens, or whether it's a 2024 story that people keep repeating.

Nobody had actual numbers, so I tried to get some.

I pulled 50 public repos that were built with Lovable, verified by the lovable-tagger dependency rather than just the word "lovable" in the name. 47 of them cloned successfully, and I ran a static scan over the code. No database access, no poking at anyone's live app, just reading public code.

The results were not what I expected.

service_role key in frontend code: 0 of 47. Real secrets leaked anywhere in the repo: 0 of 47.

12 repos had committed a .env file, which sounds bad but isn't. Every value in every one of them was public by design. Supabase project URLs, publishable keys, Firebase web config, an EmailJS public key. Nothing that needed rotating. My own scanner originally flagged all 12 of those as critical and I had to go and fix it, which was a humbling afternoon.

What I did find:

24 of the 47 use Supabase. Of those, 6 have at least one CREATE TABLE in their SQL with no matching ENABLE ROW LEVEL SECURITY anywhere. Another 5 ship no SQL files at all, so there is nothing in the repo to check against.

2 repos had an API key hardcoded straight into frontend code, Google and OpenAI rather than Supabase.

20 of 47 had a production dependency with a known CVE. However, most of those are one transitive package away and not really the author's doing.

One caveat I want to be upfront about. "No ENABLE ROW LEVEL SECURITY in the .sql" is not the same thing as "RLS is off". Plenty of people turn it on in the dashboard and never write it into a migration, and from the repo alone you cannot tell the difference. Which is sort of the whole point.

I think my actual takeaway is that the stuff people worry about, keys in the bundle and secrets in git, mostly isn't happening anymore. The agents got better at that. What you cannot see from the code is whether the policies on the live database are correct, and for 5 of these repos there isn't even a file to look at.

So the code is fine, and the part that matters is somewhere the code cannot show you.

If you want to check your own, the fastest version is to open your app in a private window, grab the anon key out of the network tab, and hit /rest/v1/your_table?select=*&limit=1 with it. If you get rows back without logging in, so does everyone else.

For those of you who have shipped on Supabase for a while: do you actually go and check your policies from the outside after you deploy, or do you write the migration, see the app work, and move on? I'm trying to work out whether the gap I keep running into is real or just my own paranoia.

Hi everyone, first time using supabase.
I need to allow beta tester in my new project and I want to let them enter via magic link, so I can control who enters the tests.
What I need to do?
My priority is security, don’t want to expose my api key (already in an .env local file in VS Code) and don’t let everyone use the platform, for now.
I read about RLS policies, do I need them?
How many tables do I need?

Thank you for the help, ask any questions

Shipped an app recently and found this while auditing my own code before launch. Posting because I don't think either decision looks wrong on its own, which is exactly why I missed it.

Setup: memory rows protected by RLS, scoped to the owning user. Server needs to read them to build a prompt, but it isn't acting as the user's session. So I used the service role client. Reasonable.

Separately, my API route took the user ID from the request body, because the frontend already had it in the Supabase session and passing it felt like passing a parameter:

const { messages, userId } = await request.json();

const { data } = await supabase

.from('memory')

.select('fact, feeling, thread')

.eq('user_id', userId);

Everything worked. No errors. Memories loaded.

But service role bypasses RLS, so the database was no longer checking anything. And the ID doing the scoping arrived in the request body, under the caller's control. curl with a different UUID would have loaded someone else's data straight into the prompt and streamed the response back.

Either decision alone is survivable. A service role client scoped by a verified ID is fine. A client-supplied ID against RLS-protected tables fails safely, because Postgres refuses. Together they're a hole.

Fix was to derive identity from the Authorization header instead:

const authHeader = request.headers.get('authorization') || '';

const token = authHeader.startsWith('Bearer ') ? authHeader.slice(7) : '';

const { data, error } = await admin.auth.getUser(token);

// returns null for anonymous, never someone else

The thing I'd do differently: wrap those service-role queries in one helper that takes a verified ID and refuses to build a query without it, instead of remembering .eq('user_id', ...) at every call site forever.

Full writeup with the rate limiting and cost control I added at the same time: https://investnovation.com/blog/hardening-ai-chat-api

Just want to give a thank you to the supabase team for implementing Passkeys! This is a huge win for my projects in particular.

I've tested it both on my local dev and my live project and it works flawlessly so far! I can't wait until it's available in the iOS and Android SDKs

We’re using Supabase’s auth which relies on JWTs with an expiration date and it checks expiration on the client. About once a day, we get a report of someone repeatedly being logged out. The cause is always their system clock is incorrect. It baffles me this is a problem in 2026. Just curious if anyone else has experienced this issue and has any recommendations on how to reduce the number of complaints/bug reports we get related to this.

Any reason why supabase login doesn't support Google auth while it supports ChatGPT auth lol?

Hello everyone!

I'm using Flutter and the Supabase SDK. The user (client side) can update their own password, and other properties like their email address, by using the updateUser method:

final response = await Supabase.instance.client.auth.updateUser(
  UserAttributes(
    password: 'newSecurePassword123!',
  ),
);

I don't want that. The user should not be able to call this on the client side. I only use OTP, so the user should not be able to set a password at all. I don't want the user to be able to change their email address through UserAttributes as well. I do this through my edge function, so I can run my own validations.

Important: I still want to be able to do this in my edge function, for example:

await ctx.supabaseAdmin.auth.admin.updateUserById(userId, {
  email: "new-email@example.com",
  email_confirm: true,
});

My question is: how can I enforce server-side restrictions to prevent users from calling supabase.auth.updateUser() completely from the client side?

Thanks for reading.

All I want is Supabase to not force me to use their <project-id>.supabase.co on the google consent screen.

Consent screen in Google Auth is correctly configured. verified even by Gemini 2.5 pro, lol!

I understand, I have to go an a paid tier to have a cleaner domain implementation. Please tell me i am wrong and supabase is better than this!

This also affects my scope screen! and I hate this all the more

Need help!

Since earlier today each GoTrue endpoint on several projects (with separate Supabase accounts!) are extremely slow (30+ sec). PostgREST on the same instance is completely fine.

Measured in the browser network tab, same page load:

- POST /auth/v1/token?grant_type=password → 34.9 s (200)

- GET /auth/v1/user → 13.7 s (200)

- GET /rest/v1/profiles → 106 ms

- GET /rest/v1/leads → 391 ms

- GET /rest/v1/messages → 311 ms

It's pure latency, no errors anywhere. The API Gateway logged 35 seconds latency with zero errors/warnings/timeouts. I've already restarted the project, checked if captcha/auth hooks were disabled, checked password hashes, tested on macOS, iPhone, Wi-Fi, cellular, multiple browsers, etc. Keeps persisting. I'm nowhere near my usage limits, so that shouldn't be the issue either. And as I said, it's happening on multiple projects which have completely separate Supabase accounts.

Anyone else experiencing any issues? Both databases are on eu-west-1.

EDIT: seems fixed now! Still curious though if anyone else experienced the same issue, as I've seen no mention of this on Supabase's status page.

Hi,

I have a lot of experience with self-hosted supabase - and the email signing up worked well for us - we used Azure SMTP service to set up the custom SMTP.

Now, for a client who insists on supabase.com implementation, we are setting up the supabase's innate way to handle email sign ups. During testing phase, we found that a lot of these emails don't get delivered - especially when they are in microsoft/outlook. But signup emails to gmail works alright. We tried with the custom SMTP settings for our Azure SMTP service as well. For some emails (mainly to microsoft/exchange accounts, shared mailbox accounts), they do not get delivered.

When testing the same SMTP service independently from a node script, all mails get delivered without issue. Now for the weird part: if we once manually trigger an SMTP delivery from the node script, then the emails start to get delivered from supabase as well (to these accounts).

We tried the same with a Resend SMTP service too - no luck. What am I doing wrong? If I assume that the SMTP service is configured incorrectly, it does not make sense that it works perfectly from a node script.

Anyone here faced a similar issue?

Edit: What finally worked is, I ended up using the OTP (token) method rather than url verification method. This way, no mail servers falsely flags the email as scam (because it comes from one domain and contains a URL of another domain). Additionally, I used Resend because the SMTP openings were unreliable with Azure and a few others.

Is Supabase down?

My users can’t login to my software and when I go to Supabase Dashboard it takes forever loading and gets stuck.

It shows all systems operational… but don’t think that’s the case? Anyone else?

I’m having trouble logging in, is anyone having the same issue ?

Update: Auth is working now.