How I Would Fix exposed API keys and missing auth in a Flutter and Firebase AI chatbot product Using Launch Ready.

How I Would Fix exposed API keys and missing auth in a Flutter and Firebase AI chatbot product Using Launch Ready

The symptom is usually obvious: the app works, but the wrong people can call your chatbot, copy your Firebase config, or trigger expensive AI requests without logging in. In business terms, that means surprise API bills, data exposure risk, broken trust, and a support headache before you have real traction.

The most likely root cause is not "hackers being clever." It is usually a rushed build where Firebase rules are too open, auth was postponed, and an AI provider key was placed in the client app or in a public repo. The first thing I would inspect is the exact path from Flutter UI to Firebase to the AI backend, because that tells me whether the key is truly exposed and whether requests are protected at all.

Triage in the First Hour

1. Check the live app for unauthenticated access.

• Open the chatbot flow in an incognito browser.
• Try sending a message before login.
• Confirm whether anonymous users can hit Firestore, Realtime Database, Functions, or any custom endpoint.

2. Inspect Firebase Security Rules.

• Review Firestore rules, Realtime Database rules, Storage rules, and any callable Functions.
• Look for `allow read, write: if true;` or rules that only check `request.auth != null` without role checks.

3. Review the Flutter codebase for secrets.

• Search for API keys in `lib/`, `.env`, `firebase_options.dart`, `google-services.json`, and any config files.
• Check Git history and CI logs for accidental secret commits.

4. Audit Firebase console settings.

• Verify Authentication providers enabled.
• Check authorized domains.
• Review service accounts, API restrictions, and project-level IAM.

5. Inspect deployment artifacts.

• Confirm whether web builds expose environment values in compiled JS.
• Check if any key is embedded in mobile binaries or web bundles.

6. Review logs and billing spikes.

• Look at Firebase usage by endpoint and time window.
• Compare request volume against actual user activity.
• Flag any p95 latency spikes or sudden token usage jumps.

7. Verify AI provider usage path.

• Determine if the client calls OpenAI, Anthropic, Gemini, or another model directly.
• If yes, treat that as a production blocker unless the key is tightly restricted and risk-accepted.

8. Snapshot current blast radius.

• Count active users, open sessions, recent writes, failed auth attempts, and recent deployments.
• Decide whether to rotate secrets immediately before touching code.

grep -RInE "sk-|AIza|api[_-]?key|secret|token" .

Root Causes

| Likely cause | What it looks like | How I confirm it | |---|---|---| | AI key shipped in Flutter client | Requests work from any device with the app bundle | Search source and compiled build artifacts for provider keys | | Firebase rules too open | Anyone can read/write chat data | Test unauthenticated access against Firestore/Storage/Functions | | No auth gate before chat use | Users can start conversations without sign-in | Walk through onboarding as a fresh user | | Backend trusts client input too much | User controls model prompt or target IDs freely | Inspect function handlers for missing validation and authorization | | Secrets stored in repo or CI variables without protection | Key appears in git history or pipeline logs | Review commit history and CI output | | Missing App Check or abuse controls | Bots hammer endpoints and inflate cost | Check request patterns and rate limits |

The biggest mistake I see is founders assuming "Firebase means secure by default." It does not. Firebase gives you strong building blocks, but if your rules are open or your AI key sits in Flutter code, you have built a public faucet for compute spend.

The Fix Plan

1. Stop the bleeding first.

• Rotate any exposed AI provider keys immediately.
• Revoke old service account credentials if they were leaked.
• If there is active abuse, temporarily disable the vulnerable endpoint or tighten rules before shipping a full fix.

2. Move AI calls off the client.

• Put all model requests behind Firebase Cloud Functions or another server-side layer.
• The Flutter app should send only user input to your backend after auth.
• The backend should hold the model key as an environment secret.

3. Add authentication before chat access.

• Require sign-in before users can create threads or send messages.
• Use Firebase Auth with email link, Google sign-in, Apple sign-in, or phone auth based on your audience.
• Block anonymous access unless you intentionally support it with strict quotas.

4. Lock down Firestore and Storage rules.

• Restrict reads/writes to authenticated users only where needed.
• Scope access by user ID or tenant ID.
• Deny broad collection access unless there is a clear business reason not to.

5. Validate every request on the backend.

• Check user identity server-side using verified Firebase tokens.
• Enforce message length limits, allowed content types, rate limits, and conversation ownership.
• Reject requests that try to override system prompts or select unauthorized resources.

6. Add abuse controls around AI usage.

• Rate limit by user ID and IP where possible.
• Cap daily message counts on free plans.
• Log prompt length, token usage estimate, response time, and error codes.

7. Remove secrets from the frontend build path.

• Move sensitive values into server env vars or secret managers only.
• Keep non-sensitive config separate from private credentials.
• Rebuild the app after cleanup so old artifacts do not keep stale references around.

8. Tighten deployment hygiene.

• Use separate dev/staging/prod Firebase projects.
• Confirm production-only secrets never touch preview builds unless intended.
• Turn on monitoring for auth failures, function errors, 4xx/5xx spikes, and spend anomalies.

9. Add App Check where it fits.

• For Firebase-backed apps with abuse risk, App Check helps reduce unauthorized traffic from non-genuine clients.
• It is not a replacement for auth or rules, but it reduces bot noise and drive-by abuse.

10. Document ownership boundaries clearly.

• The client app handles UI and authenticated requests only.
• The backend handles secret-bearing operations only.
• The database enforces data access boundaries only.

My preferred path is simple: do not try to patch this by hiding keys better inside Flutter. That only delays the next leak. The safer fix is server-side mediation plus strict auth plus restrictive rules.

Regression Tests Before Redeploy

I would not redeploy until these pass:

1. Unauthenticated access tests

• Fresh browser session cannot send a chat message successfully.
• Fresh browser session cannot read another user's chat history.
• Fresh browser session cannot write to protected collections.

Acceptance criteria:

• All protected actions return denied responses within 1 second of request start.

2. Auth flow tests

• New user can sign up and log in on iOS/Android/web as applicable.
• Logged-in user can create one conversation and continue it after refresh.

Acceptance criteria:

• Login success rate above 95 percent across test devices during QA run.

3. Secret exposure checks

• No model key appears in Flutter source files or compiled web output where it should not exist publicly accessible waypoints via source maps or logs).
• No service account JSON exists in repo history after cleanup plan is applied where avoidable.

Acceptance criteria:

• Zero secrets found by search across repo and CI logs after rotation.

4. Authorization tests

• User A cannot fetch User B's thread IDs even if guessed manually?
• Tenant boundaries hold if you have teams or workspaces?

Acceptance criteria:

• Every cross-user access attempt fails with 403-like behavior or rule denial.

5. Abuse simulation

• Rapid repeated messages trigger throttling rather than runaway spend?
• Oversized prompts are rejected cleanly?

Acceptance criteria:

6. UX checks

• Login wall explains why sign-in is needed before chat starts?
• Error states show retry guidance instead of blank screens?

Acceptance criteria:

• No dead ends on mobile screens; all blocked actions show clear recovery paths.

7. Performance sanity check

• Chat send action still feels fast after adding backend validation?
• p95 response time stays under 800 ms for non-model work plus model latency separately tracked?

Acceptance criteria:

• UI remains usable on mid-range phones; no new loading stalls longer than 2 seconds outside model generation time.

Prevention

I would put four guardrails in place so this does not come back:

1. Security review on every release

• Any change touching auth, Firestore rules, Functions, or secrets gets reviewed before merge?
• Treat open database rules as production incidents waiting to happen?

2. Secret management policy

• No private keys in client code?
• No secrets in repo comments, issue screenshots on public boards? Keep them out of Slack too when possible?

3. Monitoring with alert thresholds

• Alert on unusual AI token usage?
• Alert on auth failure spikes above baseline?
• Alert on function error rate over 2 percent for 10 minutes?

4. Product-level friction controls

• Require login before expensive actions?
• Set free-tier quotas?
• Show remaining credits so users understand limits instead of discovering them through blocked sends?

For Flutter specifically I also watch bundle size and release discipline because rushed hotfixes often create new bugs while solving security issues. For Firebase specifically I want least privilege everywhere: authenticated access only where needed; deny by default elsewhere; no broad admin privileges outside controlled server code.

When to Use Launch Ready

Launch Ready fits when you need this fixed fast without turning your product into a long consulting project. yes Cloudflare protection? Actually for this sprint: DNS,email/Cloudflare/SSL/deployment/secrets/monitoring/handover checklist? yes that's the package foundation around launch readiness plus safe deployment hygiene around your AI app so you can ship without exposing customers again? Need mention category launch & deploy hook etc yes include exactly maybe within paragraph.)

I would use Launch Ready when:

• You already have a working Flutter + Firebase prototype,
• You need production-safe deployment now,

and you do not want to guess at security fixes alone, and you're okay with me making opinionated calls quickly based on risk rather than endless discussion?

What I need from you:

• Repo access,
• Firebase project access,
• Hosting/domain registrar access,

and any AI provider dashboard access, plus screenshots of current auth flow, billing alerts, and recent error logs?

If you hand me those inputs cleanly, I can usually get from exposed-key panic to locked-down release candidate inside 48 hours, then leave you with a handover checklist your team can actually maintain?

References

1. Roadmap.sh API Security Best Practices: https://roadmap.sh/api-security-best-practices 2. Roadmap.sh Cyber Security: https://roadmap.sh/cyber-security 3. Roadmap.sh QA: https://roadmap.sh/qa 4. Firebase Security Rules documentation: https://firebase.google.com/docs/rules 5. OWASP API Security Top 10: https://owasp.org/API-Security/

---

Take the next step

If this is a problem in your product right now, here is what to do next:

• [Use the free Cyprian tools](/tools) - estimate cost, score app risk, check launch readiness, or pick the right service sprint.

• [Book a discovery call](/contact) - I will tell you honestly whether you need a sprint or if you can DIY the next step.

*Written by Cyprian Tinashe Aarons - senior full-stack and AI engineer helping founders rescue, launch, automate, and scale AI-built products.*