Base44: entity permissions, service role and backend functions

Last reviewed October 2026 · Sources: Base44 security overview, Entity security, Running a security scan

Base44's docs are direct: "You are responsible for your app's security settings… always review your permissions and run a security scan before you publish."

1. Set row-level and field-level rules on every entity

Each entity supports Row Level Security for create, read, update, delete and Field Level Security for individual fields. Values are true (everyone), false (no one), or a condition:

"rls": {
  "create": true,
  "read":   {"created_by": "{{user.email}}"},
  "update": {"created_by": "{{user.email}}"},
  "delete": {"user_condition": {"role": "admin"}}
}

• No entity with personal data uses "read": true.
• Sensitive fields (phone, address, internal notes) have field-level rules.
• After changing rules, redeploy (entities push or deploy).

2. Treat the service role like a master key

base44.asServiceRole bypasses both RLS and FLS entirely. It's only available in backend functions, and your function is responsible for its own access checks. Use it only when you must, and check who the caller is first.

3. Protect backend functions

• Called from your app via the SDK, a function runs with the signed-in user's permissions.
• Called directly over HTTP (webhooks, external services), there's no signed-in user. Verify the caller yourself, e.g. with the provider's webhook signature or a shared secret.
• Read API keys with secrets.get() inside the handler (not at module load), and set them via app settings or the CLI.

4. Run the security scan before publishing

Base44's scan flags data permission issues, exposed secrets, and backend functions anyone can run. Use Fix All carefully, then review the recommended rules yourself. Only "Acknowledge" an open function if you've confirmed it doesn't expose data or spend money (for example, AI calls).