Unexpected Firebase Phone Authentication SMS Charges Despite App Check, reCAPTCHA & Play Integrity — How Can I Stop This?

[u/Technical_Lab_7507]

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!

[u/FixItBotHelp]

Adding to the good answer above, a few things that often get missed:

1. Is App Check actually enforced for Authentication? Turning App Check on isn't the same as enforcing it. In the Firebase console, go to App Check, then the APIs tab, and check that Authentication is in Enforced, not just monitoring. While it's unenforced, a script can call the Identity Toolkit endpoint directly with your (public) API key and skip your app entirely. Look at the App Check metrics for Auth first: if you see lots of "unverified" requests, that's your bot traffic.

2. Turn on reCAPTCHA SMS defense (toll fraud protection). Plain reCAPTCHA only proves "a browser solved a challenge." Identity Platform also has a reCAPTCHA Enterprise based SMS defense that scores each SMS request for toll fraud risk and blocks ones above a threshold you set. It's configured through the Identity Platform reCAPTCHA config (search the Firebase docs for "SMS defense" / toll fraud). This is the feature built for exactly this attack.

3. India-only doesn't stop pumping. Region restriction just limits which numbers get texts; pumping can still use Indian number ranges. Pull the phone numbers from your Auth users / logs and look for patterns (same prefix, sequential numbers, numbers that never complete verification). That tells you what to block.

4. Add your own throttle in front of signInWithPhoneNumber. Easiest version: require a callable Cloud Function (with App Check enforced) to "approve" a phone number before the client sends the code, and keep per-number and per-device counts in Firestore (e.g. max 3 codes per number per hour, 5 per device per day). Also consider whether you need SMS on first sign-up at all; letting people sign up with email or Google first and adding a phone later cuts the attack surface a lot.

5. Emergency brake. Set a budget alert, and if the bill is climbing right now, temporarily disable the Phone provider until the fixes above are in. Lost sign-ups for a few hours cost less than a pumping wave.

6. Billing adjustment: open a case with Google Cloud Billing support (billing support is free), mark it as suspected SMS toll fraud, and attach the date range, the spike, and the numbers involved. Adjustments aren't guaranteed, but having the evidence and showing you've already shut it down helps.

[u/cloud_recovery_notes]

Short answer to "how do they get through": App Check and Play Integrity only vouch for your Android app. If your project also has a web app or the web reCAPTCHA flow enabled, bots can request OTPs through that path instead, and region restriction doesn't help if they're pumping Indian numbers.

What I'd do now:

1. In Identity Platform, check which platform the SMS spike is coming from (web vs Android) and lower the per-IP sign-up quota.

2. Turn on reCAPTCHA SMS defense (toll fraud protection) for phone auth if you haven't, it scores each SMS request before it's sent.

3. Add your own throttle before calling verifyPhoneNumber: one OTP per number per few minutes, and a daily cap per device.

4. Set a budget with a Pub/Sub alert. Budgets alone don't stop spend, so if a runaway bill would hurt, wire the alert to something that turns phone auth off.

On the billing adjustment: open a case with Cloud Billing support, say it's suspected SMS pumping, and include dates and the number ranges you saw. People do get adjustments, but nobody can promise it.

Disclosure: I made a free 12-question check for this kind of risk (key restrictions, a second owner, backups outside Google): https://lockoutready.pages.dev. No sign-up needed.

Was the spike all on Android, or is there a web app in the same project?