An admin page that redirects non-admin users in React or Next.js only controls navigation. Firestore and Storage rules decide whether a direct client SDK request can read or change data. Retrieve the rules actually deployed, then test ordinary users, owners, and admins against the sensitive collections in the Firebase Emulator before declaring the data protected or exposed.
This guide covers check 02: Authorization and data isolation in the Zenveus Production Readiness Standard.
For builders
Hiding an admin page does not stop someone querying Firestore directly. The deployed database rules decide which documents each person may read or change. Test those rules with different users, and check server code separately because the Admin SDK bypasses them.
A scoped repair request
Use this prompt in Lovable, Cursor, Replit, or Claude Code with the relevant server files available.
Audit my Firebase Studio app’s deployed Firestore rules, overlapping match blocks, ownership model, and admin claims. Add emulator tests for owners, other users, ordinary users, and admins; separately review Admin SDK server authorization and Storage rules. Work on a branch with synthetic data and mocked external services. Show the smallest diff, identify required adapters and deployment settings, and add allowed and denied tests that prove side effects cannot happen before checks pass. Do not disable security checks to make a test pass.The same failure may appear as
Find the failure layer
Each check removes a class of causes. Keep the first failing result, its timestamp, and the production log beside it.
Include `users`, requests, messages, organization records, and any collection subscribed to by the admin page.
A missing rules file in the repository leaves a visibility gap. Inspect deployed Firestore and Storage rules plus any custom claims or role documents used by the policy.
Test an ordinary authenticated user reading the admin collection, a user reading another user's document, an owner accessing their own data, and an admin performing the intended action. Test writes that attempt to self-assign an admin field.
A denied page with allowed direct reads signals a rule problem. A visible admin screen with denied reads may be a UI problem. Diagnose them separately.
Ranked diagnosis
A route redirect controls navigation but cannot secure direct SDK calls.
Repository files do not show the effective Firestore and Storage policies.
Rules do not restrict a user document or organization record to the appropriate identity.
A client write can change a role field if rules do not prohibit it.
Step-by-step repair
Edit firestore.rules and the trusted server workflow that assigns admin claims. Review storage.rules separately; Firestore rules do not protect Storage or Admin SDK operations.
Production safety ruleNever disable access controls, expose service keys, or add wildcard CORS as a routine shortcut.
For an admin-only audit collection, require request.auth and a trusted admin claim. Keep default access denied. Review overlapping match blocks because an allow in any matching rule can grant access.
Use the Admin SDK in a privileged provisioning workflow. Never accept a role from a client-editable profile. Refresh the user ID token after a legitimate claim change.
Run the Firestore Emulator with tests for anonymous, ordinary-user, and admin identities. Deploy the reviewed rules to the intended Firebase project using firebase deploy --only firestore:rules --project YOUR_PROJECT_ID.
Use separate Storage rules for files and server authorization for Admin SDK endpoints, which bypass Firestore rules. Owner documents also need create and update checks that prevent changing the owner or role fields.
Implementation example
rules_version = '2';
service cloud.firestore {
match /databases/{database}/documents {
match /auditRecords/{recordId} {
allow read, write: if request.auth != null
&& request.auth.token.admin == true;
}
}
}This is a narrow collection example, not a replacement for all product rules. Add explicit rules for other required paths. It assumes the admin claim is assigned by a trusted server.
Prove the repair
Run these checks with synthetic data in your test environment, then repeat the relevant acceptance checks after deployment.
When the built-in AI fix makes it worse
Pause generated changes, restore a known working branch, and capture one failing request with its logs. Change one layer and rerun the allowed and denied checks before proceeding.
Engineering handoff
We trace one production request through the complete path, isolate the failing boundary, and leave behind evidence your team can repeat.
The deployed policy, overlapping matches, and operation-specific conditions.
Trusted admin claims and fields a client must never self-edit.
Admin SDK handlers and Storage policies outside Firestore enforcement.
Emulator evidence for owner, cross-user, ordinary-user, and admin requests.
Typical repair pattern
Emulator tests show intended admin and owner access while ordinary and cross-user direct SDK calls are denied.
Before the next release
Clear answers
Firebase web configuration identifies the client app. It is not a substitute for restrictive Auth and database rules, and its presence alone is not a secret leak.
No. A client can make direct SDK calls. The Firestore rules must enforce the same permission.
Only if the effective rules and their deployment are known. Import the deployed rules into the emulator and test them.
Run the verification checks on this page against your test environment, then repeat the relevant checks after deployment. Example code needs your app's authentication, data model, and configuration; reading the guide alone does not verify your deployment.
Official documentation and library references
Free next step
The free tool helps you inspect this symptom. Its result does not establish whether the whole app is production ready.
The Verdict
We can see the symptom from here. What we cannot tell you from outside is whether it is contained or structural. A scanner collects evidence. A named senior engineer makes the decision. For $299, a named senior engineer reads your code and signs a written Verdict against the nine checks in the Zenveus Production Readiness Standard. The 48-hour clock begins when the required access and context are available. If the report does not give your developer a list they can act on, you do not pay.
The 48-hour clock starts when the required access and context are available.
Free decision aid
Get a senior view of the constraint, the evidence you have, and the next decision that removes the most risk.
No email required for this decision aid. Dismiss once and this popup stays closed for the session.