🔥 Part 12: Firebase Anonymous Auth Hijacking — How Attackers Impersonate Real Users in Flutter…

🔥 Part 12: Firebase Anonymous Auth Hijacking — How Attackers Impersonate Real Users in Flutter…

FlutterPulse

This article was translated specially for the channel FlutterPulseYou'll find lots of interesting things related to Flutter on this channel. Don't hesitate to subscribe!🚀

Firebase Authentication is widely used in Flutter apps for easy user onboarding. One common method is Anonymous Auth, where users can…

🔙 Check Previous Part [How Flutter Allows JS-to-Dart Code Execution]

Firebase Authentication is widely used in Flutter apps for easy user onboarding. One common method is Anonymous Auth, where users can start using the app without signing up.

But this convenience comes with risk.

If your Flutter app uses anonymous Firebase authentication without proper session control or user binding, it opens the door to UID collisions, identity hijacking, and data exposure — especially when tied to insecure Firestore/Realtime DB rules.

This article explores how attackers hijack anonymous Firebase users in Flutter apps — and how to defend against it.

🔍 What's the Problem?

In Flutter, anonymous auth is as simple as:

final user = await FirebaseAuth.instance.signInAnonymously();
print(user.user?.uid);

Now the user has a unique UID — but if your Firestore rules or app logic don't tightly scope data to that UID, an attacker can:

  • Forge anonymous sessions
  • Guess or steal UIDs
  • Access other users' data
  • Abuse insecure backend logic

🕵️‍♂️ Real-World Exploit Scenarios

💣 Exploit 1: UID Guessing & Enumeration

Many apps structure Firestore access like:

/users/<uid>/profile

If that UID is from anonymous auth and not well protected, an attacker can enumerate:

GET /users/q2UxD56R0m3Ngm3YfCkX/profile

And retrieve someone else's profile.

💣 Exploit 2: Token Reuse Across Devices

If a token or UID is cached locally (via SharedPreferences, for example) and reused without revalidation, an attacker with access to that token (e.g., from a rooted device or MITM) can:

  • Clone the session
  • Perform actions as the original user
  • Write to their documents (if rules allow)

💣 Exploit 3: No Auth Check in Firestore Rules

Dangerous Firestore rule:

match /users/{userId} {
allow read, write: if true; // ❌ Anyone can access any user
}

Slightly better but still vulnerable:

match /users/{userId} {
allow read, write: if request.auth != null; // ✅ but not tied to specific user
}

This should be:

match /users/{userId} {
allow read, write: if request.auth.uid == userId;
}

📉 Real-World Impact

Risk Level: HIGH

🛡️ How to Fix It

✅ Fix 1: Always Bind Firebase Data Access to request.auth.uid

Update Firestore rules to:

match /users/{userId} {
allow read, write: if request.auth != null && request.auth.uid == userId;
}

Never allow anonymous or mismatched access.

✅ Fix 2: Avoid Long-Term Use of Anonymous Auth

Anonymous auth should be temporary — used for onboarding, then upgraded:

final credential = EmailAuthProvider.credential(email: ..., password: ...);
await user.linkWithCredential(credential);

This upgrades the anonymous user to a full user — preserving their UID.

✅ Fix 3: Don't Store UID or Tokens in SharedPreferences

Instead, use secure storage:

import 'package:flutter_secure_storage/flutter_secure_storage.dart';

final secureStorage = FlutterSecureStorage();
await secureStorage.write(key: "token", value: idToken);

✅ Fix 4: Invalidate Firebase Tokens on Logout

Manually sign out and clear storage:

await FirebaseAuth.instance.signOut();
await secureStorage.deleteAll();

Also, revoke tokens on backend if applicable.

✅ Fix 5: Monitor Firestore Access Patterns

Use Firebase logging and Security Rules Simulator to detect:

  • Access from unexpected UIDs
  • Frequent UID changes
  • Wide reads (e.g., /users instead of /users/<uid>)

❌ Anti-Patterns to Avoid

✅ Developer Checklist

  • Enforce request.auth.uid == userId in Firestore rules
  • Upgrade anonymous users as early as possible
  • Use flutter_secure_storage for token/UID storage
  • Invalidate sessions and clear tokens on logout
  • Limit reads/writes to per-user scopes
  • Monitor abnormal Firebase auth activity

👀 Up Next

🔐 Part 13: SSL Pinning Bypass in Flutter — How Attackers Spoof Certificates to Intercept Traffic

Thank you for reading this article

If I missed something or made an error, please let me know in the comments. I'm always eager to learn and improve.

Give a clap 👏 if you found this article helpful.

Report Page