Firestore Security Rules: Design Queries Around Record Ownership

A private Firestore collection needs an ownership model that both its security rules and client queries can express. Fetching every document and hiding other people's records in the interface is not an access-control strategy.

Firebase's security rules documentation explains that rules do not filter a broad query into an authorized subset. Queries must satisfy the access constraints themselves. This matters as soon as a personal document application adds lists, search or sharing.

Start with the document's audience

For each document type, write down who may create, read, edit and delete it. Keep ownership separate from a display name, email label or editable author field.

MakeResume, listed in the Firestore technology collection, describes resume sections and PDF exports. The declared association does not reveal its access implementation. Resume editing nevertheless provides a useful design exercise because a document can contain information that its owner intends to share only in a finished export.

An editable private record and a public download should therefore have separately defined audiences.

Make the list query match the rule

Suppose a screen lists the current user's drafts. Its query and rules need to agree about the owner condition. A rule that restricts individual records does not make an unrestricted collection query safe or automatically useful.

Review every list surface, including archived documents, recent items and search suggestions. It is easy to protect a detail view while leaving a second query inconsistent with the intended policy.

Treat a denied query as feedback about the design. Do not broaden access simply to make an inconvenient screen load.

Protect changes to ownership

Authorization must cover writes as well as reads. Decide which identity and sharing fields a user may change, and validate the resulting record rather than trusting the form's disabled controls.

Use a synthetic document with ordinary fields and ownership fields. Attempt a valid content edit, an owner replacement and a sharing change that the caller is not entitled to make.

Keep expected outcomes in the test description. A generic permission error is not sufficient evidence unless the test also demonstrates that the allowed operation succeeds.

Review backend authority separately

Firebase documents that server client libraries bypass Firestore Security Rules and authenticate through a different authority path. A protected browser query therefore does not prove that a privileged backend endpoint enforces resource ownership.

Trace the backend caller to the requested document before performing privileged access. Administrative credentials should not turn an arbitrary document identifier into permission.

This distinction is especially important for exports, support tools and batch operations that naturally run outside the ordinary client.

Retest when sharing changes

Use two synthetic accounts, separate documents and a deliberately shared fixture in an isolated environment. Test direct reads and collection queries, then revoke sharing and repeat them.

Avoid real resumes or private customer information in logs and fixtures. Record document references and authorization outcomes instead.

If editing also coordinates several records, continue with the Firestore transaction review. Ownership decides whether an operation is permitted; a transaction decides how related changes remain consistent. Both contracts need evidence before a new sharing interface is ready.