Managed backends made it possible to ship a real app without a server. They also made it possible to ship a real app with a database anyone on the internet can read and write. The default rules are the trap.
The demo default
To get you productive fast, these platforms start you in a test mode where reads and writes are wide open. That is genuinely helpful while you are prototyping. It is a live vulnerability the moment real user data lands in it.
What "open" actually means
With permissive rules, anyone who finds your project's endpoint, which is shipped in your client code, can query your entire database. Not just their data. Everyone's. No login required. This has caused some of the largest indie data leaks on record.
Your database rules are shipped to every user inside your app. Assume an attacker has read them.
Locking it down
- Default to deny. Explicitly allow only what each user needs.
- Scope reads and writes to the authenticated owner of the record.
- Validate data shape and size in the rules, not just in your UI.
- Never rely on client-side checks alone. The client is not a trust boundary.
Verify before launch
It is easy to think you tightened the rules and be wrong. Check the deployed rules file directly as part of your pre-launch pass, and confirm an unauthenticated request actually gets rejected. "I set it up in the console once" is not verification.