Critical Firebase Misconfig Exposes E-Commerce Orders and Payment Tokens — Patch Now

Attackers aren’t waiting for you to harden your app — they’re scanning for one permissive rule.

In early 2022, researchers warn that a surge of misconfigured Firebase projects is exposing customer PII, order histories, and payment intent tokens across retail and fintech web apps.

With mobile shopping spiking post-COVID and many teams shipping client-heavy stacks, the blast radius is big: one bad rule can leak data for every user — or for anyone on the internet.

This is not a new Firebase bug. It’s a dangerous configuration pattern that keeps resurfacing in production deployments.

Key Points at a Glance

• Root cause: Firestore/Realtime DB/Storage rules left in test mode or opened too broadly.
• Impact: Exposure of names, emails, phone numbers, addresses, order contents, coupon pools, gift card balances, and payment intent references.
• Risk booster: Post-COVID mobile growth accelerated client-side builds; some teams never tightened rules after MVP launch.
• Fix: Deny-by-default, require request.auth, separate public from private paths, and enforce server-side token verification in Cloud Functions.

What Happened (and Why It Keeps Happening)

During fast iterations in 2020–2021, many web and mobile apps shipped Firebase with rules suitable for local testing but catastrophic in production. Typical anti-patterns include:

• Firestore test mode: allow read, write: if true;
• Realtime Database global allow: “.read”: true / “.write”: true
• Storage buckets wide open: permissive match /{allPaths=**} { allow read, write: if true }
• Functions trusting CORS but not Auth: accepting requests from trusted origins without verifying Firebase ID tokens server-side.

Post-COVID Mobile Surge = Bigger Attack Surface

As shoppers moved to phones, teams leaned on Firebase for speed: real-time carts, instant search, and push-to-prod agility.

The tradeoff: more logic and data paths shifted into the client. If Rules are permissive, attackers can bypass your UI entirely and talk to Firebase endpoints directly.

Who’s at Risk

• E-commerce apps storing orders, addresses, loyalty IDs, and contact info.
• Fintech / BNPL flows save payment intent IDs, referral codes, or KYC artifacts.
• Any project that relied on client checks while leaving Rules lax or never revisited them post-launch.

Observed Impact Patterns

• Data exposure: PII and order contents are freely readable.
• Account abuse: Over-permissive writes allow profile overwrites or malicious content seeding.
• Fraud enablement: Access to coupon pools or gift card balances; enumeration of payment intent references.
• Compliance fallout: GDPR/CCPA/PCI-adjacent trouble if personal data was accessible.

Technical Anatomy: Where Things Go Wrong

Technical Examples

Never ship this in production (Firestore):

rules_version = ‘2’;service cloud.firestore {  match /databases/{database}/documents {    match /{document=**} {      allow read, write: if true;    }  }}

Public read/write (Realtime Database):

{  “rules”: {    “.read”: true,    “.write”: true  }}

World-writable Storage bucket:

rules_version = ‘2’;service firebase.storage {  match /b/{bucket}/o {    match /{allPaths=**} {      allow read, write: if true;    }  }}

Server-side verification concept (pseudocode):

// Always verify identity server-side:const idToken = (req.headers.authorization || ”).replace(‘Bearer ‘, ”);try {  const decoded = await admin.auth().verifyIdToken(idToken);  // proceed with decoded.uid} catch {  return res.status(401).send(‘Unauthorized’);}

How Attackers Chain It (Typical Flow)

1. Discover your Firebase project endpoints (public JS, mobile config, leaked IDs, or guessable hostnames).
2. Probe Firestore/RTDB/Storage with unauthenticated requests.
3. If reads are allowed, enumerate object paths (e.g., /orders, /users, /coupons).
4. If writes are allowed, tamper with carts, profiles, or coupon balances.

Quick Self-Check (Only for Projects You Own)

Legal note: Test only assets you are authorized to assess. Unauthorized access is illegal.

• Firestore/RTDB: Use the Emulator Suite/Rules Playground. An unauthenticated read must be denied.
• Storage: Attempt listing/fetching a known non-public path without credentials — should be denied.
• Functions: Ensure every HTTP function verifies a valid Firebase ID token (or equivalent) on the server.

Safe Defaults You Can Drop In Today

Lock Down Firestore (deny by default):

rules_version = ‘2’;service cloud.firestore {  match /databases/{database}/documents {   // Default deny    match /{document=**} {      allow read, write: if false;    }   // User profile: only the owner    match /users/{userId} {      allow read, write: if request.auth != null                          && request.auth.uid == userId;    }   // Orders: creator can read/update their order    match /orders/{orderId} {      allow create: if request.auth != null;      allow read, update: if request.auth != null                          && resource.data.userId == request.auth.uid;    }  }}

Lock Down Realtime Database:

{  “rules”: {    “.read”: false,    “.write”: false,    “users”: {      “$uid”: {        “.read”:  “auth != null && auth.uid === $uid”,        “.write”: “auth != null && auth.uid === $uid”      }    },    “orders”: {      “$orderId”: {        “.read”:  “auth != null && data.child(‘userId’).val() === auth.uid”,        “.write”: “auth != null && newData.child(‘userId’).val() === auth.uid”      }    }  }}

Lock Down Cloud Storage:

rules_version = ‘2’;service firebase.storage {  match /b/{bucket}/o {   // Public assets only (if truly needed)    match /public/{allPaths=**} {      allow read;            // read-only public      allow write: if false;    }   // User-owned files    match /users/{uid}/{allPaths=**} {      allow read, write: if request.auth != null                        && request.auth.uid == uid;    }   // Everything else denied    match /{allPaths=**} { allow read, write: if false; }  }}

Immediate Mitigations: 10-Step Playbook

1. Switch to deny-by-default. Start with allow: if false and open only exact paths you need.
2. Require request.auth everywhere user data is touched.
3. Separate public vs. private. Keep a dedicated read-only /public/* and nothing else world-readable.
4. Never store secrets or full PAN data in Firebase. Keep payment tokens to provider references only.
5. Rotate any exposed keys/tokens. Assume compromise if they were stored alongside orders.
6. Enable App Check where supported to cut automated abuse (defense-in-depth, not a substitute for Rules).
7. Add CI checks. Fail builds if rules contain allow … if true in production configs.
8. Log & alert on denials. Spikes in Rule denials often indicate probing before exploitation.
9. Review Cloud Functions. Enforce server-side auth; don’t rely on CORS or origin alone.
10. Run a data retention pass. Purge unnecessary PII and old orders to shrink the blast radius.

Detection, Triage, and What to Watch

• Unusual read spikes on /orders, /users, /coupons paths.
• Storage access logs showing object listings without Auth headers.
• Support tickets about “missing cart items” (may indicate write abuse).
• Security scans flagging web-accessible JSON under your Firebase endpoints.

FAQ

Is this a Firebase vulnerability? No — it’s misconfiguration. Firebase enforces what your Rules allow.

Can I rely on client checks? No. Treat the client as untrusted. Rules and server-side verification are mandatory.

Do I need any public access? Only for truly static, non-sensitive assets. Everything else should require Auth.

Bottom Line

Mobile usage soared after COVID, and attackers noticed. In Firebase, one permissive rule is enough to leak your store.

Lock rules down, verify identity on the server, and make deny-by-default your new normal. If you haven’t audited your Rules since launch, today is the day.

About the Author

Roman Fedytskyi is Head of Software Development Office at JetSoftPro, where he leads large engineering teams delivering fintech, e-commerce, and digital transformation projects.

He has more than seven years of experience in frontend and full-stack development, with previous roles at Datamart, Multicora, 2Solar Software, FaceIT, and N-iX.

His work has ranged from building advanced analytics tools to developing platforms for renewable energy and peer-to-peer lending systems.

Roman holds a Master’s degree in Mathematics from Ivan Franko National University of Lviv and a Master’s degree in Management and Administration from the Ukrainian Catholic University.