In this chapter
We'll meet security rules, authentication integration, and authorization as the necessary, separate layer on top of realtime sync — declarative, per-path conditions checked on every read, write, and subscription, working identically across mobile and web clients.
The Problem in Real Life
The order-tracking app now updates instantly, on every device, the moment anything changes. Mike realizes what that actually means: every subscribed client sees every real-time write, immediately — including, right now, every single customer's order, on every single customer's phone.
Sarah never wrote a line of access control. Realtime sync was never the same problem as "who's allowed to see this."
It's fast. It's also currently showing everyone everyone else's orders.
Mike
Real-Time for Everyone vs. Real-Time for the Right People
Fast sync isn't safe sync
Every subscribed client saw every write in this Act's own examples — genuinely unsafe if shipped exactly as demonstrated.
Security rules check every request
Declarative, per-path conditions evaluated on every read, write, and subscription — not just at login.
Authentication answers "who"
A real, verified identity has to travel with every request before authorization can mean anything.
Authorization answers "allowed to do what"
The actual decision: is this specific, known identity allowed to touch this specific piece of data.
Security Rules & Authorization
Security rules are how a real BaaS platform (Firestore's own rules language is the common real example) answers this directly: declarative, per-path conditions evaluated on every single read and write, checking who's asking before any data — or any realtime update — is actually sent. A rule for orders/{orderId} might require the requester's own identity to match that order's customerId field, or belong to a staff role, before allowing a read at all.
This depends entirely on authentication integration: the BaaS platform has to genuinely know who's asking, not just that someone is connected. A real client authenticates first — a login, a token — and every subsequent request (including every realtime subscription) carries that verified identity along with it.
Authorization is the actual decision built on top of that identity: not just "who is this," but "is this specific person allowed to do this specific thing, to this specific piece of data." This is precisely why Mike's realtime dashboard, built and demonstrated across this Act's last three chapters, would be genuinely unsafe shipped as-is — every example so far used two generic, anonymous clients with no identity and no rule ever checked, which was the right amount of complexity for learning sync itself, and the wrong amount for anything real.
This shows up identically on mobile applications and web applications — the exact same security rules apply regardless of which client platform is asking, which is part of the real appeal of a BaaS: write the access-control logic once, server-side, and every client — a phone app, a web dashboard, a support tool — is bound by the same real rules, instead of each platform having to enforce it separately and hope every implementation agrees.
Key Takeaway
Realtime sync answers "how does data get to the right screen, fast." Security rules and authorization answer a completely separate, equally necessary question: "should this screen even be allowed to see this data at all." A fast, unsecured realtime system doesn't fail quietly — it succeeds at exactly the wrong thing, instantly, for everyone.
Why This Matters
Every realtime mechanism this Act has built so far has been genuinely unsafe by omission, on purpose, to keep the sync mechanics clear — this chapter is the honest reminder that a real system needs this layer before any of it ships, not as an afterthought bolted on later.
GreenMart now knows realtime sync and access control are two separate, both-necessary layers — fast delivery, and the right delivery only to the right person. What it actually costs, and who ends up controlling, to run a real system built this way is exactly where the final chapter goes.
