Hello,

I use Expo (Android) with the Firebase JS SDK for Auth and Firestore. The debug provider works, but real Play Integrity seems to need u/react-native-firebase/app-check, and I can't find an official guide for Expo.

Has anyone already made this work with the JS SDK, or did you have to move Auth and Firestore to React Native Firebase?

Thank you.

I am busy testing an app that I have built, and I am using the no-cost Spark plan in Firebase for authentication and Cloud Firestore to store the users' data.
I am able to see the number of reads, writes and deletes, but I can't seem to find a way to see how much of the 1 GiB total Cloud Firestore storage I have used?

If someone could point me to where I could find Cloud Firestore Stored data usage in the no-cost Spark plan, I would really appreciate it.

Hola, comunidad. Buen día.

Estoy buscando apoyo con un problema que llevo intentando resolver en Firebase y que me está impidiendo actualizar las reglas de seguridad de Cloud Firestore de un ERP en producción.

He probado diferentes alternativas, tanto desde Firebase Console como desde PowerShell con Firebase CLI, pero sigo recibiendo:

HTTP 503 — The service is currently unavailable

El error aparece al validar o intentar publicar las reglas en:

POST https://firebaserules.googleapis.com/v1/projects/PROJECT_ID:test

También he observado el mismo error en el endpoint de creación de Rulesets.

¿Qué he probado hasta ahora?

1. Verificar autenticación y conexión

• Firebase CLI versión 15.25.1.

• Node.js versión 24.14.0.

• Windows PowerShell.

• Autenticación válida.

• Acceso a la base de datos Firestore confirmado con HTTP 200.

• Puedo consultar y respaldar las reglas actualmente activas.

2. Compilar un archivo mínimo de reglas

Creé un archivo pequeño, con una sola regla de acceso denegado, y ejecuté:

firebase deploy --only firestore:rules --project PROJECT_ID --config firebase.json --dry-run

Resultado: HTTP 200. Compilación correcta.

Esto demuestra que el proyecto puede validar al menos un Ruleset sencillo.

3. Compilar mis reglas completas

Mi archivo original tiene aproximadamente 204 KB e incluye permisos por roles, almacenes, auditoría y validaciones de distintos módulos del ERP.

Resultado: HTTP 503.

4. Eliminar comentarios y líneas vacías

Reduje el archivo de 204,061 a 142,952 bytes, conservando las instrucciones de las reglas.

Resultado: HTTP 503 nuevamente.

5. Recompilar exactamente las reglas que YA están activas en producción

Consulté la release activa mediante Firebase Rules API, descargué su contenido y ejecuté nuevamente la validación con --dry-run.

El archivo activo tiene 202,654 bytes.

Resultado: HTTP 503.

Este último punto es el que más me preocupa: las reglas que Firebase ya tiene publicadas tampoco pueden volver a compilarse.

6. Intentarlo directamente desde Firebase Console

Intenté editar y publicar manualmente las reglas, pero aparece el mismo problema.

Resumen de resultados

No se ha publicado ningún cambio y las reglas productivas continúan activas.

¿En qué punto estoy?

Estoy considerando que el problema podría estar relacionado con los límites internos del compilador de Firebase Rules, la complejidad de funciones y expresiones, o algún problema del servicio al procesar archivos extensos.

Sin embargo, todavía no tengo evidencia suficiente para confirmar la causa.

El archivo contiene numerosas funciones auxiliares, validaciones RBAC y bloques match. Necesito mantener esas restricciones porque protegen información financiera y operativa del ERP.

También he intentado obtener soporte oficial, pero todavía no he conseguido una solución.

¿Alguien ha experimentado algo similar?

Quisiera preguntarles:

1. ¿Han recibido HTTP 503 al compilar reglas grandes de Firestore, aunque las reglas mínimas funcionen?

2. ¿Conocen límites de complejidad del compilador que puedan provocar este comportamiento?

3. ¿Existe alguna metodología recomendada para identificar qué función o bloque ocasiona el problema?

4. ¿Han conseguido solucionarlo reorganizando funciones o simplificando expresiones sin alterar los permisos?

5. ¿Conocen alguna forma de escalar este problema al equipo técnico de Firebase cuando no se recibe respuesta de soporte?

No quiero reemplazar las reglas productivas por unas simplificadas sin comprobar su equivalencia de seguridad.

Agradecería mucho cualquier orientación, experiencia similar, documentación técnica o solución que hayan aplicado.

Puedo compartir fragmentos relevantes de las reglas y registros del error, sin exponer información sensible.

¡Muchas gracias por su tiempo y apoyo!

Update:

Vercel's bot protection was blocking Google from hitting my website with a JS challenge. GoogleBot was coming through fine, but the verification requests come from user agent "Google" and from Google datacenter IPs and are still being challenged (not blocked) by default Vercel rules. I had to had a bypass to fix it.

===========

Original post:

I have been using Firebase auth in a production app for five years. I recently started getting alerts that my project is not in compliance. The complaints are listed below.

The issues don't make sense. My privacy policy is 5,900 words and very detailed about what we collect. My home page is not behind a login. I've requested a manual review multiple times and I keep getting back the same template email.

My site gets millions of crawls a month from GoogleBot, but I wonder if maybe their verification process is getting blocked? I can't imagine why else they would think my homepage is behind a login.

Has anyone run into this problem? How did you resolve it? I have about a month until this starts causing me problems.

These are the complaints from Google:

Your privacy policy page does not have sufficient content. We were unable to confirm your app's compliance. Please update your privacy policy to clearly and sufficiently detail your app's data collection and usage, then retry. Learn more

Your home page is behind a login page. We were unable to confirm your app's compliance. Please update your home page to allow users to view information about your app without needing to login, then retry. Learn more

Your application is not compliant with the Google APIs Terms of Service. We were unable to confirm your app's compliance. Please update your home page to clearly outline your application's purpose and ensure it does not use Google APIs for AI NCII (AI-generated Non-Consensual Intimate Imagery), then retry. Learn more 

I've published a Firebase Function Kit (the replacement for extensions) that gives you, and whoever else you designate, a user administration control panel for your app. Basically it shows you a list of users from Firebase Authentication, or lets you look one up by email or UID, and then lets you do things like disable or delete the account, change their name or photo, and edit custom claims. There is a special custom claim that grants access to the admin panel.

Installation isn't quite as simple as "install the function kit" because you also have to be able to log in, but it's still pretty simple, especially if you're using Firebase Hosting. Basically you (1) install the kit with "firebase functions:kits:install", then (2) map a URL path to call one of the functions.

I have an unreleased version, not really ready for release, that has some more sophisticated features, like copying user metadata to a database for better search and sort, and additional ways to customize. I'm not likely to make it free and open source, but if you're interested in additional features and can support a bit of development work, let me know.

The kit is here: https://www.npmjs.com/package/@aldel/superusers

I think this might be the first third-party function kit released. The only other kit I've even seen is the official one for Firestore -> BigQuery.

Last week bots used my app's SMS login to request 1,744 verification codes in nine days. 1,230 different numbers, 1,152 IPs, about 50 countries. Three of those requests ended in a real sign-in. Cost before I noticed: €57.53. Before October 30 the SMS line in my bill had always been zero.

What found it: the budget alert at 50%, then Billing → Reports grouped by SKU. Almost all of it was "SMS messages sent in Region …" from Identity Platform. Everything else in the project was about €0.40.

What didn't help: App Check. 99% of the requests on Authentication were verified, attack days included. The requests came from the real app on real phones. Attestation passed.

What I did, in order:

1. SMS region policy limited to the countries where I have users. This stopped most of it with one change.

2. A blocking function that runs before each SMS, with limits per number and per number prefix.

3. A daily check that compares codes sent and sign-ins per country. It emails me when a country gets codes and almost no sign-ins.

4. Budget alerts stay on. They were the only thing that told me.

My mistake: the first version of the filter refused two code requests within 60 seconds. When iOS verification fails at the first attempt the app retries on its own: 4 calls in 22 seconds. A real user got "An internal error has occurred". Count attempts, not calls. Test every change on a real number. Firebase test numbers never send an SMS.

Billing support said no at first. After one polite escalation they refunded €57.24 as a one-time courtesy.

The signal I trust most now is codes sent vs successful sign-ins. Is anyone watching something better?

Hey everyone!

I'm a student developer, and for the past few months I've been working on a project called Crick Auction - a real-time multiplayer IPL auction simulator where you can create auction rooms, invite friends, pick franchises, and compete against each other to build the best squad.

Live project: https://crickauction.in/
GitHub: https://github.com/Shaurya01836/ipl-auction

The idea was to recreate the IPL auction experience as closely as possible, rather than just making a simple bidding website.

What I've built so far

• Real-time multiplayer auction rooms.

• Live bidding with synchronized timers across connected clients.

• Private rooms and public lobbies.

• Franchise selection and budget management.

• Franchise bots with different bidding strategies.

• Squad management with overseas player restrictions.

• Franchise strength ratings to evaluate completed squads.

• Auction history, live chat, and auction summaries.

Tech stack

• React 19 + Vite

• Tailwind CSS

• Firebase Realtime Database (primary live auction engine)

• Supabase PostgreSQL (public rooms, leaderboard, and persistent data)

• Firebase Authentication

Where I'm struggling

While building this, I've realized that making something work and making it reliable under real-world traffic are two very different things.

1. Firebase RTDB bandwidth limitations

Currently, I'm using Firebase Realtime Database on its free Spark plan, which comes with a 10 GB/month download limit.

With the traffic the application is receiving, I'm concerned that this limit could be exhausted within around 10 days.

Real-time bidding involves frequent updates, and multiple connected clients receive these updates simultaneously.

I'm trying to figure out whether I should:

• Optimize the existing RTDB architecture to reduce unnecessary downloads.

• Move the live auction engine to Cloudflare Durable Objects.

• Consider another backend or real-time infrastructure.

• Use a hybrid architecture where different services handle different responsibilities.

I'm particularly interested in hearing from people who have handled real-time applications with similar workloads.

2. Auction reliability and synchronization

Although the auction is functional, it isn't completely robust yet.

There are still some edge cases and issues around synchronization, bidding, timers, and handling unexpected connection problems.

I want to make sure that two users cannot end up with inconsistent auction states, that bids are processed correctly, and that reconnecting users don't experience unexpected behavior.

3. Scalability and infrastructure

Ideally, I'd like the platform to support:

• Around 100–300 concurrent users.

• Approximately 5–20 simultaneous auction rooms.

• Frequent real-time bidding updates.

• Reliable synchronization without excessive bandwidth consumption.

I'm working with a very limited budget, so moving to expensive paid infrastructure isn't really an option right now.

What I'd love some advice on

1. Is Firebase RTDB a reasonable choice for this kind of workload, or am I approaching the architecture incorrectly?

2. Has anyone migrated a real-time multiplayer application from Firebase RTDB to Cloudflare Durable Objects? Was it worth it?

3. What are some practical ways to reduce Firebase RTDB bandwidth consumption without compromising the real-time experience?

4. How would you architect the backend for 100–300 concurrent users and multiple simultaneous auction rooms?

5. If you've built something similar, what reliability issues should I be looking out for?

I'm not claiming the project is production-perfect. There are still things I need to improve, and that's exactly why I'm posting here.

I've put a lot of effort into building this, and I'd genuinely appreciate feedback, architectural suggestions, or even criticism of things I've done incorrectly.

If you've worked with Firebase RTDB, WebSockets, Durable Objects, or real-time multiplayer systems, I'd especially love to hear your experience.

Thanks for reading!

Building a small gallery for my old school batch (I'm an ex-student, unpaid, school is a charity trust). No Cloud Functions since they need Blaze.

Only verified rkmv<number>@gmail.com emails that are in a roster can sign up, votes are one doc per question per student, an admin can block people. The rules have emulator tests.

Demo with fake data: https://smriti-gallery.pages.dev Rules and tests: https://github.com/codewithpom/smriti (look at gallery/firestore.rules)

Please roast the rules. There are also good first issues if you want to help: https://github.com/codewithpom/smriti/labels/good%20first%20issue

I build with Firebase almost every day and keep the local emulators running all day, and two things wore me down. The suite is heavy with Java to install, a heap past 22 GiB on our app, out-of-memory crashes, and data gone at every stop unless you export it. And it's hard to see what your app is doing. It had become almost unusable for us, so I built a replacement: Firenook. It's open source, and I'd really like to know what you think.

Lighter, with no Java. One npm package with a native engine. On a real app's two-hour workload it peaked at 2.11 GiB where the official emulator reached 22.57 GiB, and answered writes in 5.1 ms against 208 ms at the median. That 40× is under load; on an idle emulator a write is only 1.5× faster (how it was measured). Add --keep-data and Firestore, Auth and Storage come back with your data in about half a second, with no export at every stop.

A new UI, built from scratch. It sits on the Emulator UI's port (screenshots) and shows:

• every function call with what triggered it, its request, answer, duration and logs; open a failed one, read the stack, run it again;

• your rules beside each allow or deny, with the line that decided it, plus a playground and coverage;

• an inbox of the verification emails, sign-in links and SMS codes Auth would have sent;

• Pub/Sub messages, Cloud Tasks queues and Eventarc events, which the official UI has no pages for;

• Firestore and Storage to browse and edit, even with millions of documents.

The terminal shows each function call as one line with its outcome and stack, and npx firenook mcp add lets Claude Code, Cursor or VS Code use all of it.

Trying it:

1. npx firenook init --adopt --dry-run checks your project and changes nothing.

2. npm install --save-dev firenook (keep firebase-tools for deploying).

3. Change firebase emulators:start to firenook emulators:start. --only, --project, --import and --export-on-exit carry over.

Your firebase.json, rules, Functions code and app stay as they are.

It's still new and I'm sure it misses things. If something behaves differently from the official emulator, please tell me here or open an issue. That's the most useful feedback I can get.

Repo: https://github.com/firenook-dev/firenook · Docs: https://firenook.dev

Hey everyone!

I’ve been working on an npm package called @rootvarma/firebase-electron, built to simplify Firebase integration in Electron applications.

I recently published it on npm, and it recorded 519 downloads between October 29 and November 5.
It’s exciting to see something I’ve built getting downloads, and I’d love to see more developers try it out.

If you’re building desktop applications with Electron and Firebase, here’s the package:
📦 npm: https://www.npmjs.com/package/@rootvarma/firebase-electron

I’d genuinely appreciate feedback, suggestions, bug reports, or contributions.

I’m looking to improve it based on real-world developer requirements.

Thanks to everyone supporting open-source projects!

We're running Google UAC 3.0 campaigns for our Android app and noticed something unusual in Firebase Analytics.

Our subscription_convert event count is significantly higher than our in_app_purchase event count. Our in_app_purchase event includes both free trial subscriptions and direct paid subscriptions.

The overall conversion value looks normal. It seems that some subscription_convert events report a value of $0, while others report the correct subscription revenue.

Our dev team has tried several fixes, but none of them seem to work.

Has anyone experienced something similar?

I am trying to create a user to send emails to Pagerduty so we can be alerted on certain conditions. If I add the user with the email address it sends an email and waits for someone to click a button to verify the email, but I can't do that with an email received by Pagerduty. Is there a way for a project owner to manually verify a user's email address in Firebase?

I had around 18 Projects on there, some really old and never used but never bothered to clean them out. Today I'm starting a new project which has importance and another one in the coming months. Firebase says I have reached my limit but no where does it state (That I can find) what my limit is. I have deleted them down to only 6 left which run as community projects that I pay a couple quid for a month which I don't mind, but still unable to create any new ones unless I request them, which google responded telling me to pay $50 extra for. Why is this? What is the actual limit? I don't really want to have multiple google accounts signed to run some basic app hosting.

If you receive Firebase push notifications in an Electron app with firebase-electron, the token can come back fine and every send still fails with MismatchSenderId.

The package registers GCM with a built-in server key instead of your vapidKey. FCM ties the token to that sender, so a send from your Firebase project does not match. Messages that do arrive can also fail to decrypt, because the Web Push dh, salt, and auth fields are not parsed.

I published a fork that registers with vapidKey as the sender and decrypts those Web Push fields:

https://www.npmjs.com/package/@rootvarma/firebase-electron

Install:

npm i u/rootvarma/firebase-electron

vapidKey is required. Pass the same appId, apiKey, projectId, and vapidKey you already use. The first launch registers again and emits a new token.

Has anyone recently encountered a 200-per-day GetOobCode quota on a Firebase project using the Blaze plan?

We run a production mobile app with nearly 10,000 registered users. We don't recall encountering this daily limit during previous signup activity, so this appears to be a recent issue for us. However, we don't have historical quota values to confirm whether the limit itself changed.

I released an app update, which may have caused a spike in legitimate registrations. Email verification requests then started failing with HTTP 429.

The error response explicitly includes:

Quota exceeded for quota metric 'Get OOB Code'

and limit 'Get OOB Code per day'

quota_metric: identitytoolkit.googleapis.com/get_oob_code

quota_limit: getOobCodePerDayPerProject

quota_limit_value: 200

quota_unit: 1/d/{project}

quota_location: global

reason: RATE_LIMIT_EXCEEDED

We also reproduced the same error using the Firebase Admin SDK's generateEmailVerificationLink(), authenticated with a service account for the same project. Generating a link without sending an email still hits the same 200/day quota.

The public documentation lists 100,000 address verification emails/day and 1,000,000 address verification links/day for Blaze. We understand that quotas scale with user count and that additional abuse protections may apply, but we couldn't find documentation explaining this specific 200/day quota.

https://firebase.google.com/docs/auth/limits

This is affecting real users who cannot complete email verification. We have already contacted Firebase Support and are waiting for a response.

Has anyone experienced this exact quota, especially recently?

Did you find out why it was applied, or get it increased?

Is there any way to inspect or request an adjustment to this specific quota outside of Support?

We're trying to understand the cause rather than assume this is a Firebase bug.

I'm interested in trying out the experimental support for Dart cloud functions, but before I do I'm interested if anyone has tried it out, what the experience has been, pitfalls, etc. I have a Flutter app with a small user base, so it's a good candidate for trying it out, but I'm also hesitant that long-term support is lacking given its experimental status.

I am building an app around Firestore's direct client SDK, realtime listeners and offline cache. I want to keep that architecture, but I cannot find a supported native way to cap an otherwise authorised user's billable reads/writes across devices and concurrent connections.

The existing feature request dates from April 2023 and currently has 73 votes:

https://firebase.uservoice.com/forums/948424-general/suggestions/46561738-implement-rate-limiting-for-read-and-write-operati

There are concrete adoption concerns in its comments: Al3life reports moving to Supabase for this feature, capTarget archery says it may rule Firebase out for future projects, and Anatole Couasnon describes adding an API despite choosing Firebase for direct access. These are individual reports, not a survey, but they match the concern blocking my confidence in launching.

I am not asking for authentication or permissions to be replaced. Rules limit what a user can access, but a query-size limit does not limit how often an allowed query runs. App Check attests clients; it is not a configurable allowance for each UID. Budget alerts do not stop usage. Cloud Armor in front of my own API does not control the Google-managed Firestore endpoint the SDK calls.

A custom API/SSE/WebSocket gateway could control traffic routed through it, but rebuilding native listener synchronisation, reconnect handling, cache behaviour and authorisation adds infrastructure, cost and complexity. That is not a viable equivalent for this application. An after-read trigger alone would also be too late to stop the triggering charge or a concurrent burst.

What I would like Firebase to provide is a simple console or rules-level policy, enforced by the service: per-UID rolling/burst allowances shared across devices, plus a database/project backstop. It needs to address document/query volume, writes, initial listener snapshots, subsequent billable updates and reconnects, with clear charging and quota-exceeded semantics. I appreciate that the implementation may be more complex than the setting exposed to developers.

I submitted a detailed feature request yesterday and have asked our Google Cloud contacts to escalate it. Is there a Firestore product owner who can give this an explicit status or link it to the right backend tracker? If a supported solution now preserves direct SDK listeners and actually enforces the allowance, I would welcome a documentation link. Otherwise, please treat this as an adoption and cost-abuse concern that needs an owned response.

Related history: https://github.com/firebase/firebase-js-sdk/issues/647

Official App Check limitations: https://firebase.google.com/docs/app-check

Budget guidance: https://firebase.google.com/docs/firestore/quotas

Hi all! At my company we develop a white-label app, so we have 60+ Firebase projects. Keeping Remote Config in sync across all of them through the console is painful: changing one parameter can mean opening dozens of projects and clicking through each one.

So I built fbrcm, a terminal manager for Remote Config. It has an interactive TUI, a full CLI, and an MCP server. It’s free, open source (MIT), not monetized, and not affiliated with or endorsed by Google or Firebase.

It can

• Discover all the projects your account can access and work with them together

• Get, update, add, delete and duplicate parameters, conditions and groups across many projects at once, with filters to pick the projects (fuzzy, prefix, exact, or expressions on the actual values)

• Compare and promote configuration between projects

• Browse version history, roll back, restore, import and export templates

• Client and server templates are both supported

• --dry-run to preview a change, and --json output for scripts and CI

A few things I want to be upfront about:

• Credentials: since this is a third-party tool, it’s reasonable to be careful about handing it cloud access. It requests the cloud-platform Google OAuth scope, which is very broad. I know that’s a big ask, but it’s the only scope that lets all the features work (project discovery plus reading and publishing templates). Everything runs locally, with no backend and no telemetry, and the code is open so you can judge the risk yourself. If you’d like tighter limits, you can use a dedicated service account and grant it IAM access only to the projects you want to manage.

• AI-assisted: the project is largely vibe-coded, as noted in the README, so bug reports on edge cases are very welcome.

Docs: https://fbrcm.yumaa.dev · Code: https://github.com/yumauri/fbrcm

I’d love feedback, especially from anyone else managing Remote Config across many projects. What does your workflow look like, and what’s missing?

I am developing a React + TypeScript website called WEAR KLAY using Firebase Authentication.

When I try to customize the Password Reset Action URL in Firebase Console → Authentication → Templates, I get the error "An error occurred updating action URL."

The Network response is:

400 INVALID_ARGUMENT: EMAIL_TEMPLATE_UPDATE_NOT_ALLOWED

Firebase's troubleshooting page says email templates cannot be changed and suggests Google Cloud Support may help in some cases.

Is there a way to resolve this restriction for my Firebase project?

Posting this so someone else doesn't learn it the way I did.

I run a small bar crawl planner (React + Firebase + Vercel). Back in June my Google Places budget got drained. My first guess was a crawler hammering the app. It wasn't. The page that calls Places was behind a login, so nothing could drive the UI into spending money.

What actually happened: my VITE_GOOGLE_PLACES_API_KEY was compiled into the public bundle. Anyone who opened devtools had it. I had an HTTP referrer restriction on it and thought that was enough. It isn't, the Referer header is just a header and anyone can set it from curl.

What I changed:

1. The key never ships to the browser anymore. One Vercel serverless function holds it and makes the Places calls.

2. The function checks a Firebase ID token on every call before it spends a cent. Signed-out visitors get an anonymous Firebase user, so the app still works without signup, but every request has a uid behind it.

3. Per-user rate limits stored in Firestore (a rateLimits/{uid} doc written with the Admin SDK, so the client rules can't see or touch it). Mine are 10/min and 80/day for nearby search.

4. App Check enforced on top, so a token minted outside my site doesn't get far.

5. A hard daily quota in Google Cloud as the last backstop, plus billing alerts. The rate limiter fails open if Firestore hiccups, so the quota is the thing that actually guarantees a ceiling.

One Vercel gotcha that cost me about 12 deploys: I split the proxy into api/places/nearby.ts, api/_lib/guard.ts and so on. Every call 500'd with FUNCTION_INVOCATION_FAILED before running a single line. Vercel's ESM bundling wasn't shipping my shared local modules (only node_modules got bundled), so the function crashed on import. I ended up with one self-contained api/proxy.ts that switches on an action field. Ugly but it works.

If your Maps or Places key is a VITE_ or NEXT_PUBLIC_ variable right now, it's public. Worth 20 minutes to check.

Happy to answer questions about the setup.

Hi everyone,

I'm facing an issue with unexpected SMS charges in my Firebase project, and I'm looking for advice from anyone who has experienced something similar.

I suspect my Firebase Phone Authentication flow may be experiencing SMS pumping or automated OTP abuse, but I'm not sure how it's happening despite having several security measures in place.

Security measures already enabled:

• Firebase App Check is enabled.

• SMS region restrictions are configured for India only.

• Firebase reCAPTCHA is activated.

• Play Integrity is enabled for app verification.

Despite these protections, I'm concerned about unusual SMS activity and unexpected billing.

My questions:

1. How can automated bots abuse Firebase Phone Authentication when App Check, reCAPTCHA, and Play Integrity are already enabled?

2. Can attackers still trigger OTP requests using emulators, modified apps, or automated devices?

3. What additional rate-limiting mechanisms should I implement to restrict OTP requests per device, IP address, or phone number?

4. Are there any Firebase Authentication settings that can further limit SMS abuse or prevent excessive OTP requests?

5. Has anyone successfully received a billing adjustment from Firebase or Google Cloud after experiencing suspected SMS pumping?

I'd appreciate any practical advice, especially from developers who have dealt with this issue in production.

Thanks in advance for your help!

Hello everyone and thank you for reading this post. I am screwed and cannot figure out how to find a solution myself. So, here I am.

I have basic and free Android app. I am using Firestore as my backend. I have users and usersPrivate documents and everything is separated nicely. Only those whom are authenticated to perform a particular action is allowed. For the past few weeks bots somehow found my app and attacking me with DOW (Denial of Wallet). I have banned these bots' UIDs but the problem is their auth token remains valid for an hour. I have AppCheck and they are somehow bypassing it.

They are unable to read any documents, so the bill is not coming from that but the cost of 1 read per rejection in security rules (checking banned accounts). I could deny all auth tokens but that hurts the honest users as they cannot perform any actions within the app. The bots definitely know about the 1-hour period of an already issued auth token expiry and coordinating their attacks with 50 mins apart.

Cumulatively, they are hitting me with about 30k requests denials a minute, so I closed the app for now. How the hell do I stop them? Rate limiting also does not help because that is more expensive to handle than Firestore's one read cost.

Help me please!

Anyone experiencing 500 error? Cloud function v2 it seems. US Central 1

UPDATE 22:25 UTC: Google appears to have fixed it. Cold starts are working again (seen i n us-central1) even for functions still on automatic updates. The on-deploy redeploy below is still a valid fallback if it comes back. Outage window seen: about 21:15 to 22:25 UTC.

FIX (works immediately, confirmed by several people): redeploy each function with the runtime pinned instead of auto-updated.

gcloud functions deploy FUNCTION_NAME --gen2 --region REGION \
  --runtime-update-policy=on-deploy --source PATH_TO_BUILT_FUNCTIONS

• It keeps the function's triggers, secrets and settings.

• For --source, use your functions folder after building it: package.json, package-lock.json and the compiled output, no node_modules.

• A normal firebase deploy does not fix it: it keeps automatic updates on, so the function lands on the same broken runtime.

• One deploy per function, so script it if you have a lot. I'm running 6 at a time.

Write-up with checks, a curl probe and a one-liner listing the functions still on automatic updates: https://gist.github.com/mrbenji/5da8f50a875b8e0bbb7141bd24caa726

What's happening

Since about 21:15 UTC (2:15 PM Pacific) on Oct 22, 2nd gen functions on Node 22 can't start new instances. It's been reported in us-central1, us-east1 and northamerica-northeast1, across manyunrelated projects. Google's status page shows nothing yet.

• Warm instances keep working, so it looks intermittent.

• Callables show up in the browser as CORS errors, because the OPTIONS preflight returns 500.

• Firestore triggers and scheduled functions fail too.

• Cloud Run reports "container failed to start and listen on the port ... within the allocated timeout," and the container writes no logs at all.

It's Google's side, not your code: a five-line hello-world Node app fails the same way on the auto-updated Node 22 runtime and works with automatic updates off. New Node 22 base images (22.23.4) were published that day.

Check whether you're affected

gcloud functions describe FUNCTION_NAME --gen2 --region REGION --format='yaml(buildConfig)'

automaticUpdatePolicy means it's on automatic updates; onDeployUpdatePolicy means it's pinned.

Afterwards: Firestore-triggered functions without retries drop failed events, so plan a backfill for anything that happened during the outage. If you're affected, please reply with your region and open a support case so Google can see how widespread this is.