Row-level security
Rules on each entity that decide who can create, read, update and delete which rows, checked on the server before any data is sent.
Also called RLS and access rules.
If a rule says you can only read your own tasks, other people's tasks never reach your browser. They're never sent at all, so there's nothing to dig out of dev tools.
Each Base44 entity gets four rules, one per action:
"rls": {
"create": true,
"read": { "created_by": "{{user.email}}" },
"update": { "created_by": "{{user.email}}" },
"delete": { "user_condition": { "role": "admin" } }
}Anyone can add a task. You can read and edit only your own. Only admins can delete.
The mistake I see most is an entity with no rules at all, which is open to everyone, including visitors who never signed in. Close second: filtering rows on the page and calling it security. By then the data has already arrived.
Lesson 7 of What's BaaS? (opens in a new tab) is all about this, with a wall of parcel lockers as the picture. It's also where I start every security review.
Related:Entity, Security scan and Service role.
Where I've used it: