Office Hours · Session #44
Security for BeginnersRLS & CRUD
A beginner-friendly security walkthrough designed to make RLS feel un-scary. Sam explained authentication, RLS, CRUD, field-level security, roles, and route protection using a "castle, lockers, and magic wristbands" ELI5 app (built by Base44's proprietary base one model). He attempted a live security scan on a fake CRM (card/deal/customer entities) — the scan detected the open permissions correctly but the "fix all" button failed to apply (builder was having a slow day), so he explained the one-by-one fix instead.
The session leaned into the new automatic, out-of-the-box security that ships with every new app. Q&A covered simulating logins, default-open behaviour, admin visibility over gradebook/student data, large data caches, third-party scanners (cautioned against), the testing agent, and old-app custom login migration.
Nailed to the gate
Notices from the keep
6 announcements read out during the session.
Security Now Ships Out Of The Box
Every new Base44 app now comes with baked-in, contextual security from the first prompt — a big improvement over a year ago when the onus was entirely on the user. You don't even need to ask for it.
Enhanced Security Scan
The Dashboard → Security scan (also accessible from Publish) audits all entities and auto-suggests/locks down RLS. Runs holistically across every entity. (Note: the live "fix all" failed this session — a builder hiccup, not normal behaviour.)
Mobile Push Notifications — End Of Month Target
Sam gave a mid-session update: mobile push notifications are scheduled for end of month (no guarantee it lands — roadblocks happen, but that's the goal).
Thursday's Session: Import From Other Websites
Previewed the Thursday session on easily migrating from external third-party websites into Base44.
Contra Challenge — $15,000, 5 Days Left
Lily flagged the official Contra challenge in chat: a $15k "build anything" challenge (100 credits just for signing up), judged by Base44's Daniel and Sarai (publicly listed on the challenge page). Sam confirmed it's legit.
A Newsletter Is Going Out
Sam warned the mods to expect traffic — a Base44 newsletter is going out ASAP.
The guided tour
Walk the castle, floor by floor
9 lessons from the walkthrough — each one a chamber of the keep.
The drawbridge
The Golden Rule of "It Stops Working On Publish"
If an app works in the preview window but behaves differently the moment you publish (things don't display), it is 100% of the time a security issue — never anything else.
The locker hall
RLS = Row Level Security
RLS is applied to database entities (your tables). The security scan looks at each entity and asks "is the RLS on this safe?" If you understand RLS and CRUD, you understand security.
The locker hall
CRUD = Create, Read, Update, Delete
The only four things you control per entity, and "control" means WHO can do them: Create — who can add a new record. Admin-only, signed-in users only, blank (anyone, even non-logged-in), or anything in between. Read — who can read an entry. Often locked to "must be a user." Update — who can change/modify a row. Delete — who can delete a row. Access it from any table → top-right → Permissions.
The locker hall
What the Scan Does
It scopes records to their owner — e.g. "scope the customers to the owner of each customer" so a user only sees their own records, not everyone's. Often an admin rule is layered on top (creator can see it, no one else, but admins can too). Just running the scan at a routine level gives you basic security across the whole app.
The diary shelf
Field-Level Security ("Secret Diary Pages")
Within a record a user can read, individual fields/lines can be locked. Analogy: a diary where some pages have a tiny lock only the teacher can read. It's the lock on individual pages, not the whole diary. (Sam's mallet-shop example: let someone see the products but hide the hammer discounts.)
The wristband stand
Roles ("Teachers and Students")
Every app ships with users and admins by default. You can add unlimited custom roles (caretaker, supervisor, stock administrator, admin-A through admin-Z) and define exactly what each can do and see. Don't hand out admin casually — admins have overarching visibility.
The VIP room
Route Protection ("The VIP Room")
Pages that exist and are part of the app but are gated so only the right wristband gets in — e.g. an admin backend on a CRM. A guard sits at the route and blocks anyone without the right role.
The whole castle
The Castle Analogy (Whole Security in One Metaphor)
Authentication = the castle guard / walls / keys (turn it off = anyone does anything; add Google/email login = armoured guards at the door). "Who goes there" = login checks your ID and gives you a wristband to pass. RLS = the magic label on each locker checking it belongs to you before you touch it. Field-level security = the tiny lock on individual diary pages. Roles = teachers (admins, go anywhere) vs students (users, own classroom/locker only). Route protection = VIP-only rooms.
The deep cellar
Large Data Caches
Sub-5,000 records → just a database entity, accessed by backend function. Anything larger → workarounds, or implement an external DB provider (e.g. Firebase, or hundreds of others — pick the cheapest) and pull from it.
CRITICAL: Default Is OPEN
The live repair
The scan, the jammed lever,
and the one-by-one fix
Check your work through the spyglass
Testing RLS As A User
Old way: incognito window (Ctrl+Shift+N Chrome / Ctrl+Shift+P Firefox). New way: top-right → three dots → Act as user → pick a user from the dropdown. WARNING: it's PROD data — you're interacting live as that user.
The gatehouse queue
Questions shouted over the wall
24 questions answered during the live session.
Showing 24 of 24 answers
Raise the portcullis
Watch the full session
The whole walkthrough, exactly as it happened — replay it from the gate.
Office Hours #44 — Security for Beginners — RLS & CRUDYouTube · opens in a new tabBefore you ride off
Decrees to carry home
If an app works in preview but breaks on publish, it is ALWAYS a security/RLS issue — nothing else.
Default is OPEN — a CRUD action with no rule set means all users have access. The scan's job is to scope it down.
Understand RLS + CRUD (create/read/update/delete, controlling WHO) and you understand security.
Every new app now ships with contextual security out of the box; run the Dashboard → Security scan before going live and layer an admin rule on top of owner-scoping.
Test RLS with "Act as user" (top-right three dots) — but remember it's live prod data.
As the owner you can always see everything; give restricted access via custom sub-admin roles, never full admin.
Don't trust random third-party security scanners — Sam won't vouch for their authenticity.
From the armory
Everything shown or shared during the session.
- "Castle, lockers & magic wristbands" security ELI5 app (built by base one)
- Fake CRM demo (Spark CRM — card/deal/customer entities)
- Firebase (external DB provider example)
- The Contra Challenge ($15k, 5 days left, judged by Daniel & Sarai)
- Unofficial Office Hours archive / YouTube VODs
- Game-build session (upcoming — spritesheets, assets)
- YouTube VOD