"Make sure your database has access rules turned on" is advice I've repeated often on this blog, and it's correct as far as it goes. It's also incomplete on its own, because a rule that's technically turned on can still be far too permissive to actually protect anything. Here's a concrete reference for what a genuinely good rule checks.
The four questions a good access rule answers
- Who is asking? A rule needs to identify whether a request is even coming from a logged-in user at all, rather than treating every request the same regardless of authentication.
- Is this their own data? For anything tied to a specific user, a good rule checks that the requester's own identity actually matches the record being requested, not just that they're logged in as someone.
- What are they trying to do? A read, a write, an update, and a delete are different operations, and a rule that only restricts reading while leaving writing or deleting wide open is only doing half its job.
- Does this fit the row's own state? Some data has its own conditions worth checking, whether an order is still editable, whether a document has been marked as shared, rather than a flat yes-or-no independent of the record's actual state.
What a weak version of "turned on" looks like
The most common weak version is a rule that only checks whether a request is authenticated at all, letting any logged-in user reach any row regardless of who it actually belongs to. Technically, access rules exist. Practically, they don't restrict much of anything, since being logged in as any account is enough to pass the check.
How to use this as an actual reference
For each table in your database holding anything meaningful, walk through these four questions specifically, rather than confirming only that a rule exists. A table can have a rule enabled and still fail every one of these four checks in practice, and it's the specific content of the rule, not its mere presence, that actually determines whether the data is protected.
Why this is worth keeping as a reference, not a one-time task
New tables get added as an app grows, and each one needs this same walkthrough, not just the ones that existed when access rules were first set up. Keep this list somewhere you'll actually revisit every time a new table gets created, rather than treating access control as a single setup step you complete once and never look at again.