The sibling comment by ubercore has the right link. And your concern is important, since without security, why not just expose your db to the frontend directly?
At a high level, the permission system:
1. Is a whitelist approach (you can't do anything by default)
2. Allows you to specify query shapes that are allowed to be run by the current user. This prevents queries of the wrong shape from ever hitting the database, helping with scalability.
3. Has a fallback to full javascript rules which can depend on the data on disk. A little slower than the query rules, but allows much more flexibility where you need it. And you can combine them with a query rule to do a rough first pass of what is acceptable.
Ultimately, the permissions system is designed to prevent unfettered database access, but it also has an eye towards performance in the case of DOS attacks. Horizon overall attempts to use only indexed queries, low resource usage operations etc, so you don't accidentally invite DOS attacks .
Now, I'm not claiming we're DOS proof or anything, but I just intend to mention we have an eye towards it when we talk about security.
Security is the same as the clients DB writes are rejected if they are modifying fields in ways that are not permitted (eg: changing a trouble ticket from "submitted" to "approved"). This can make some of the security easier to audit as most of the business logic security is in one place rather than scattered about in dozens of API calls.
While the exact technical details for these real-time DB based front ends are different, the basic thinking is the same of never trust the client and its costly to transmit info to the client.
The nice thing about having the DB directly on the client is that it makes CRUD apps much easier to make as you have to build less bespoke framework to get data to/from the client and verifying things conform to business logic. If you are not building a CRUD app you will want to evaluate other methods for a better fit.