Firestore is publicly accessible by default. Every read and write that a browser issues hits the database directly without passing through your own backend. The mechanism that keeps that arrangement safe is Security Rules: a separate declarative file, deployed alongside your app, that pattern-matches against incoming requests and evaluates whether to allow them.
Rules can read the authenticated user's UID, custom claims attached to their JWT, the document being requested, and even the contents of other documents in the same database. That breadth is what makes them powerful — you can express access policies like "users can read posts in groups they are a member of" without writing a line of server code — and also what makes them dangerous. A rule that looks right at a glance can leak data under a query pattern the author never considered.
The most common Security Rules failure mode is over-permissiveness. Wildcard match statements at the top of the file let through requests that more specific rules below would have rejected. The rules engine evaluates statements with allow-on-match semantics — the first matching allow wins — and a poorly placed wildcard quietly defeats the precise rules underneath. The Firebase Auth internals post in this topic walks through the security-rule patterns that survive an audit and the specific mistakes that flag during penetration testing.