Firebase Auth Misconfiguration Bugs Worth Reporting
Firebase API keys in mobile apps are expected. The bug is almost never "API key exposed." The bug is what that key can still reach when Security Rules or Identity Platform settings are wrong.
Rules before fireworks
Export or infer Firestore and Storage rules from behavior. Anonymous sign-in enabled? Email enumeration soft-disabled? Create two users with email/password or anonymous auth, then try reads against paths the app uses for profiles, chats, or billing mirrors.
A typical probe looks like reading users/{victimUid} or users/{victimUid}/secrets/current with user A's ID token. If rules say allow read: if true or only check request.auth != null, that is a direct finding. Same pattern for Storage paths like /user_uploads/{uid}/.
Watch for rules that compare request.auth.uid to a client-supplied field inside the document path incorrectly, or that trust request.resource.data.owner on create without locking it. Create-then-read races show up when anyone can create a document with someone else's uid as a field the UI later trusts.
Realtime Database rules are a separate grammar. Do not assume Firestore lockdown covers *.firebaseio.com legacy paths still referenced from an old SDK build.
Auth configuration footguns
Check sign-in methods the app enables. Phone auth without adequate abuse controls can become spam; for bounty, focus on logic: can you attach a victim's phone to your account without verifying, or link OAuth providers in a way that overwrites an existing account?
Account linking bugs show up when the client calls linkWithCredential and the backend project allows an unverified email to take over a verified one. Prove it with two inboxes you own. Password-reset flows that reveal whether an email exists may be informational depending on program rules—pair them with a higher impact chain if you can.
Custom claims are another angle. If a Callable Function mints admin: true based on a request body field rather than a server-side allowlist, swap the claim and call an admin-only HTTPS Function. Emulator suite configs accidentally left pointing at production are rare but devastating; confirm project IDs in the client before escalating.
App Check gaps do not equal authz bypass by themselves. Still note when abuse APIs lack App Check while the rest of the app enforces it—rate-limited anonymous creation plus open rules is a common combo.
Responsible proof and report shape
Do not scrape entire collections. One document with a canary field under a second account is enough. Avoid destructive deletes on shared sandboxes. Prefer Firebase Auth test users and emulator-like staging projects when the program provides them.
A useful report states: project ID (usually public), exact rule logic you inferred, request with ID token for user A, response body of user B's canary, and whether the app binary or web config made discovery trivial. Include the SDK surface (Firestore REST, client SDK, Callable) so triage does not waste time on the wrong console blade.
Recommend least-privilege rules, per-document owner checks, App Check where it fits the threat model, and disabling unused providers. Rotate any service account JSON found in apps or CI artifacts. OWASP's mobile and API guides still apply—Firebase just makes the misconfig louder when rules default open during a prototype that reached production.