Firebase Auth and API Key Abuse Hardening for Solo Flutter + Firebase Founders in 2026

By gspteck Editorial · Published 2026-10-05 · Last verified 2026-10-05

Most indie Flutter + Firebase apps ship with Firebase Authentication turned on in an afternoon: email/password, maybe Google sign-in, maybe phone auth. The defaults are reasonable, but a few settings decide whether a bot can brute-force sign-ins, enumerate your users’ email addresses, pump SMS charges onto your bill, or reuse an API key for a billable Google API you never meant to expose. This 2026 guide is a one-hour hardening pass and a quarterly review cadence for solo founders: API key restrictions, authorized domains, email enumeration protection, sign-in quotas, SMS region policy, and optional blocking functions. It pairs with the Firestore Security Rules review cadence, App Check staging habits, and Cloud Functions cost alerts and budgets. Console labels move; always confirm against the official Firebase and Google Cloud docs linked below. Portfolio: gspteck.com.

Start with the right mental model: Firebase API keys are not secrets

The Firebase docs on using and managing API keys are explicit: API keys for Firebase services only identify your Firebase project and app. Authorization comes from Google Cloud IAM, Firebase Security Rules, and App Check. That is why the keys in your Flutter firebase_options.dart, google-services.json, or GoogleService-Info.plist can live in your repository and app bundle without being treated like a password—as long as the setup follows Firebase’s guidance.

The risk is not that someone “steals” the key. The risks are:

Over-broad API allowlists. A key that is allowed to call billable non-Firebase APIs can let anyone who extracts it from your app spend your quota.
Weak data rules. A public key plus open Security Rules is an open database; that is a rules problem, covered in the rules review cadence.
Auth endpoint abuse. Bots can call sign-up, sign-in, and phone verification endpoints directly, bypassing your Flutter UI.

Diagram showing a Flutter app's public Firebase API key, key restrictions, and the real authorization layers: Security Rules, IAM, App Check, and Auth settings — Firebase API keys identify your project; authorization lives in Rules, IAM, App Check, and Auth settings.

Step 1: Audit API key restrictions (15 minutes)

Open the Credentials page for your production project in the Google Cloud console and review every key, not just the ones Firebase created.

Firebase-provisioned keys (usually named like “Browser key (auto created by Firebase)” or “Android key (auto created by Firebase)”) are automatically restricted to Firebase-related APIs. Confirm the API allowlist contains only the Firebase-related APIs you need.
Never add billable or AI APIs to a public key. Firebase’s docs call out specifically that the Generative Language API (Gemini Developer API) should never be on the allowlist of a publicly accessible key or a key used for other services.
Use a separate key per non-Firebase API. If your app uses Maps, Places, or another Google API, create a dedicated key restricted to that API, per the same Firebase guidance.
Add client restrictions where they fit. Google Cloud’s Adding restrictions to API keys describes HTTP referrer (website), IP, Android app, and iOS app restrictions and recommends both client and API restrictions on all keys. For a Flutter web build, restrict the browser key to your domains (for example example.com/* plus *.example.com/*).
Test restrictions in staging first. Android app restrictions depend on package name and signing certificate fingerprints; a release signed by Play App Signing has a different fingerprint from your local debug build. Roll changes into a staging project, run debug and release builds, then copy the settings to production.

Step 2: Prune authorized domains

Firebase Authentication only allows OAuth redirects and email-action links (password reset, email verification, email-link sign-in) to domains in the Authorized domains list under Authentication settings. The redirect best practices page notes that your continue URL must be in that list.

Remove preview, demo, and old marketing domains you no longer control. A domain that lapses and is re-registered by someone else should not remain trusted.
Keep production and staging domains in their respective projects instead of adding staging hosts to production.
If your Flutter app is mobile-only, keep the list minimal; you still need the domains used by email-action links.

Three cards for the Auth hardening pass: API key audit, authorized domain pruning, and email/password protections — The one-hour hardening pass: keys, authorized domains, and email/password protections.

Step 3: Email/password protections

If you use Firebase’s managed email/password sign-in, the Firebase security checklist recommends two settings that solo founders often miss.

Email enumeration protection. Google Cloud’s email enumeration protection guide explains that it stops auth endpoints from revealing whether an email is registered, which attackers use for credential stuffing and targeted phishing. Projects created on or after September 15, 2023 have it enabled by default; older projects do not. If your Flutter app was created earlier, check this setting, and update any UI that relied on “user not found” vs “wrong password” error codes to show one generic message.
Tighter sign-in quotas. The checklist recommends tightening the default quota for the identitytoolkit.googleapis.com endpoints to slow brute-force attempts. Pick a limit that comfortably exceeds your real peak (check your sign-in counts after a launch spike) and review it if you run a big promotion. Firebase also publishes Authentication limits you should know before changing anything.

Step 4: Phone auth and SMS pumping

Phone auth is where abuse turns directly into money. Firebase’s Authentication FAQ notes that since September 2024 projects must be linked to a Cloud Billing account to use the SMS service, and describes SMS traffic pumping: bots trigger large numbers of verification SMS to premium or unexpected regions.

Set an SMS region policy. Per Google Cloud’s SMS regions guide, you can choose allowlist-only or denylist-only, and only one can be active. For stronger protection Google recommends allowlist-only covering just the regions you serve. The phone auth setup docs note that new projects default to allowing no regions.
Watch the verification success rate. The SMS regions guide defines it as verified phone count divided by sent SMS count per region; rates above 75% are typically acceptable, and a low rate in a region where you have no users is a strong abuse signal. The Firebase FAQ adds that rates below 50% commonly indicate traffic pumping.
Keep budget alerts on. Phone auth costs land on the same billing account as Functions—reuse the alerts from the cost alerts guide.

Four-step flow to stop SMS pumping: measure sent versus verified SMS per region, spot low success rates, restrict with an allowlist SMS region policy, watch billing — Phone auth abuse loop: measure, spot, restrict, and keep budget alerts on.

Step 5 (optional): Blocking functions for sign-up rules

If you have upgraded to Firebase Authentication with Identity Platform, blocking functions let you run code before a user is created (beforeUserCreated) or before sign-in completes (beforeUserSignedIn). Indie use cases include rejecting disposable email domains, requiring verified email before sign-in, or limiting sign-ups during an abuse wave. The docs note the function must respond within 7 seconds, so keep it fast, and remember a buggy blocking function can lock out every new user—deploy it to staging first and keep a quick way to disable it, similar to the Remote Config kill-switch pattern.

A quarterly Auth review cadence

Keys: list all API keys; confirm API allowlists and client restrictions; delete unused keys after checking no build uses them.
Domains: prune authorized domains to what you control today.
Email/password: confirm enumeration protection is on and sign-in quotas still fit your traffic.
Phone: review SMS sent vs verified by region; adjust the region policy.
Users: scan for bursts of new accounts from one pattern of email domains; spot-check with the Authentication users list.
Pair: do it in the same session as the rules review, App Check metrics, and budget check, then note any changes in your ops log next to Crashlytics and Performance Monitoring notes.

Grid of six quarterly Firebase Auth review items: keys, domains, enumeration protection, quotas, SMS regions, and paired ops checks — Quarterly Firebase Auth review cadence for solo founders.

Checklist for indie Firebase Auth hardening

Firebase keys contain only Firebase-related APIs; no Generative Language API on public keys.
Separate, restricted keys for Maps or any other Google API.
Browser key restricted to your web domains; mobile restrictions tested in staging with release signing.
Authorized domains pruned to domains you control.
Email enumeration protection enabled; generic sign-in error message in the Flutter UI.
Sign-in endpoint quota tightened to a sensible ceiling.
SMS region policy set (allowlist preferred); success rate reviewed by region.
Budget alerts active; blocking functions (if used) staged and reversible.

Key takeaways

Firebase API keys are identifiers, not secrets—restrict what they can call instead of hiding them.
Enumeration protection and quotas blunt credential stuffing on email/password sign-in.
SMS region policies plus success-rate monitoring are the main defense against SMS pumping bills.
Authorized domains and blocking functions deserve the same staging-first discipline as rules and App Check.
A quarterly one-hour review is enough for most solo Flutter + Firebase apps.

Sources

Operational guidance for indie developers—not a guarantee against abuse or unexpected charges. Confirm current API key behavior, quotas, SMS pricing, region policies, and Identity Platform requirements in the official Firebase and Google Cloud documentation for your projects. Last verified 2026-10-05.