Blog
What should a Firestore rules audit cover? Define access journeys, test denials, and review Storage and server paths before requesting a quote.
A mobile app can work flawlessly in a demo while allowing overly broad access to its data. With Firebase, the question is not merely whether someone is signed in. You need to know which records each account can read, change or delete.
If you are preparing a launch or taking over an existing product, a Firestore rules audit should produce testable scenarios and a prioritised list of fixes. Here is how to scope that work before requesting a quote.
List the collections and journeys that handle sensitive data: profiles, teams, orders, documents, subscriptions or private content. For each operation, identify who should have access: a visitor, owner, organisation member, administrator or server process. Rules can only be assessed against a clear product access model.
Include opposite cases: a user can reach their own data, another user cannot, and a member of one organisation cannot read another organisation's records. If you support anonymous accounts, define their permissions before and after sign-in too.
Firebase documents automated rules tests with the Emulator Suite. A useful audit checks permitted reads and writes alongside denials: another user's document, a role change, a forbidden field or an unexpected deletion. Test the app's queries using the identities and document paths that the product actually uses.
The deliverable should be reproducible scenarios, the rules reviewed, observed gaps and proposed fixes. A console screenshot or a manual “it works” check does not establish data isolation.
If the app handles attachments, review Cloud Storage rules as well: reads, uploads, size, file type and path ownership. Firestore rules do not automatically protect stored files.
Review Cloud Functions, server calls and service accounts separately. Firebase states that server client libraries bypass Firestore Security Rules and use IAM permissions. A function receiving a document ID must therefore check whether the caller is allowed to act on it.
To scope an audit, provide the data structure, rules files, main journeys, role list and available environments. Arrange limited, named project access; avoid sharing credentials or copying production data without a clear need.
Ask for a report that separates demonstrated unauthorised access, areas that were not tested and defence improvements. Fixes should include regression tests and checks that legitimate journeys still work. Blocking every client may close an exposure, but it is not a usable release. The scope and price then depend on the paths, roles and services actually involved.
Conclusion
Before launch, you should be able to answer a simple question: who can access which data, through which path, and what test proves it? A bounded review of Firestore rules, Storage and server access gives you a concrete basis for fixes and an estimate.
Ready to build?
If this resonates with your challenge, let's have a conversation about what you're building.