Office Hours #77 · 13 October 2026
Preview works.
Live doesn't.
It's security.
The fundamentals of row-level security and role-based permissions, on any platform.
Security Week opens
Secure by
understanding.
Security Week begins with the fundamentals, which apply on any platform, not just Base44. Using the cat-walking demo, Sam reproduces the most common support complaint: "my preview works but my live app doesn't". It is almost always a permission rule, because the preview runs as a super admin and bypasses every rule. Robert adds the cache and incognito checks.
They explain row-level security (RLS) through CRUD: who can create, read, update, and delete records in each table. A booking form should let anyone create but only admins read. Unprotected tables can be scraped even when no page displays them. Role-based permissions (RBP) hide pages, buttons, and routes by role, and field-based rules such as age or region can personalise what users see.
They close on the security scan: run it after a block of building, then retest as a logged-out visitor, a logged-in user, and an admin, because the scan tends to over-secure. Thursday covers debugging and turning Claude or Codex into a pentester.
Test from every seat
Three views,
every change.
- 01
Logged out
What can a stranger see or scrape?
- 02
User
Can they see only their own data?
- 03
Admin
Does the back office still work?
- 04
Custom roles
Marketing, staff, walkers: check each journey.
7 lessons
Know it exists.
Then ask for it.
- 01
Preview ≠ live is usually permissions
The preview runs as a super admin, so it ignores every security rule. If a live page shows a 404 or blank page, send screenshots of both views, with the URLs visible, to the builder and describe the difference. Also rule out the cache with an incognito window.
- 02
RLS is CRUD per table
Each table controls who can create, read, update, and delete its records: everyone, logged-in users, creators only, or admins. A public booking form needs open create and admin-only read, update, and delete.
- 03
No security is the default
Without rules, anyone can read, edit, or delete everything, even data that no page shows. Robert describes leaderboards where open update rules let people set scores of 80 billion.
- 04
RBP controls what each role sees
Role-based permissions hide buttons and block routes. A non-admin never sees Control panel and is redirected if they type the URL. Ask the builder to create roles and role-specific dashboards.
- 05
Fields can gate content too
Use a field, such as an over-18 flag or a region, when roles are too blunt. Sam prompts a landing page that changes for UK and US visitors.
- 06
Max security breaks apps
A fully locked public app can't show its landing page. A private app is close to impenetrable but only works for invited users. Security is a balance you design.
- 07
Scan, then retest every role
Build a large block, run the security scan, apply the fixes, and then test as a logged-out visitor, a user, and an admin, plus any custom roles. Act-as-user makes this quick. Your own app_users table is secured by default.
The week
ahead.
As stated on 13 October 2026.
- Update 01
Security Week schedule
Tuesday covers fundamentals, Wednesday is a security drop-in, and Thursday covers debugging, MCP-powered white-hat testing, and a live security guide app.
- Update 02
This week's sprint: build a guide
On Thursday, the Launchpad opens for an app that teaches something you know or want to learn.
- Update 03
No top-ups for now
Top-up credits are not available. Feedback is welcome on the feedback board.
Security questions.
Plain answers.
Every substantive question from the hour, including answers the hosts could not confirm.
11 of 11 answers
No. This week is about securing your own apps.
Maximum security would break public pages such as landing pages. A private app is effectively that setting.
Yes. Describe each role's journey and the builder applies RLS, RBP, and field-level rules. Knowing these concepts exist is what lets you ask for them.
Use a field such as date of birth or an over-18 flag, not a role, and filter content by it.
It favours answers it thinks you want. Guardrail it, say why it was wrong, and give it sources.
It would be too hard to moderate. Thursday shows how to turn Claude or Codex into your own pentester through MCP.
Yes, as different user roles. Testing logged-out visitors is harder.
Whichever you configure in the agent's settings.
Post in Showcase, then link that post in chit-chat. Help test other people's apps in return.
Come to Thursday's session. Robert also suggests a soft launch with a few users before full marketing.
Not currently. Share feedback on the feedback board.
Watch the original
RLS and RBP,
explained.
Open on YouTube The discussion opened with Discord audio problems, so YouTube carried Sam's camera only. Robert shared a permissions documentation link whose exact path is not in the captions.
Bring this to your next build
Lock the
right doors.
- 01
If preview works but live doesn't, check permissions first.
- 02
Set CRUD rules on every table, even ones no page displays.
- 03
Use roles for areas of the app and fields for finer filtering.
- 04
Run the security scan after a build phase, then retest every role.
- 05
Never test logged in as yourself. Use act-as-user or a second email.
Keep learning
Further reading.
- Base44 permissions examples
- Previous security session VOD
- Base44 feedback board
Unofficial community archive · All Office Hours