Skip to content
LeakHunt

Who can do what

Permissions, explained

Three separate locks guard a Base44 app. Most leaks happen when someone thinks one lock covers all three.

Three locks, three jobs

  1. Lock 1 · App visibility

    The front door

    Who can open the app at all?

    Public
    Anyone on the internet. No sign-in needed.
    Private
    Only invited people, signed in. Needs a paid plan.
    Workspace
    Everyone in your Base44 workspace, signed in.

    Set in: Dashboard > Overview > App Visibility

    Choosing who can access your app

  2. Lock 2 · Data permissions

    The filing cabinets

    Who can create, read, update or delete the records in each table?

    Four actions
    Create, Read, Update and Delete are set separately for every table.
    Any one rule
    A person who matches any one rule gets in.
    Whole tables
    In the builder, rules apply to a whole table.

    Set in: Each table's Permissions page, or ask the AI chat

    Managing data permissions

  3. Lock 3 · Backend functions

    The back office

    What does your server code do for whoever calls it?

    Check the caller
    A function should confirm who is calling before it returns data.
    Service role
    Code running as the service role skips table rules. It must do its own checks.
    Secrets
    Keys live in the secrets vault, reachable only from the backend.

    Set in: In the function code, and Secrets in your dashboard

    Base44 security: An overview

A fourth door: the editor. Admin and User roles only change what people can do in the live app. Only collaborators and the app owner can open the editor and dashboard.

Pick a rule, see the catch

Base44 gives you four rule types for each table action.

What it does

Lets in anyone who can use the app.

Good for

Public catalogues, blog posts, anything you would happily print on a poster.

Watch out

On personal data this is Level 1: the table is open to strangers. Choosing it clears the specific rules on that action, after a confirmation.

  • A person who matches any one rule gets access, so one broad rule can undo a strict one beside it.
  • You cannot remove the only rule covering an action. Add another rule first.

Who gets in where

Five kinds of caller, and what each lock lets them do.

  • A stranger

    Not signed in

    Open the app
    Only if the app is Public.
    Table data
    Only where a table rule lets everyone in.
    Editor
    Never.

  • A signed-in user

    Role: User

    Open the app
    Public apps, workspace apps, or Private apps they were invited to.
    Table data
    Only what each table's rules allow.
    Editor
    Never. Roles do not open the editor.

  • An admin

    Role: Admin

    Open the app
    Same as a user.
    Table data
    Wherever a rule checks for the admin role, plus any broad rule.
    Editor
    Not unless they are also a collaborator.

  • A collaborator or the owner

    Builders

    Open the app
    Yes.
    Table data
    As their role allows in the live app. New collaborators start as Admin.
    Editor
    Yes: the editor and the dashboard.

  • A backend function

    As the service role

    Open the app
    Not applicable.
    Table data
    Skips table rules, row and field level, whatever they say. The function must check.
    Editor
    Not applicable.

A note on field-level rules: the builder's Permissions page applies rules to whole tables, while Base44's developer entity docs also describe field-level rules in the entity schema. Check which one your app uses. Entity security docs

Test it as someone else

  1. 1Open a table's Permissions pagePick the table that holds the data you worry about most.
  2. 2Click Test Permissions in previewChoose a sample person to view the app as them.
  3. 3Switch with “You're acting as”Try a stranger-like user, an ordinary user and an admin. Look for data they should not see.
  4. 4Click Exit modeChanges made while testing are saved to that person's data, so use sample users, not real ones.

Words you will meet

Tap a word for the plain-English meaning. Terms marked “general” are not from Base44's docs.

Table (entity)

A list of records of one kind, such as bookings or customers. Base44's developer docs call tables entities.

Record

One row in a table: a single booking, a single customer.

Role

A label on a person, such as Admin or User. Rules can check it. It changes what they do in the live app, not whether they can open the editor.

Collaborator

Someone invited to build the app with you. Collaborators and the owner are the only people who can open the editor and dashboard.

Visibility

The front-door setting: Public, Private (paid plan) or Workspace.

Backend function

Server code your app runs on request. It can return data a table rule would have blocked, so it must check its caller.

Service role

How backend code runs when it acts as the app itself. It skips table rules, row and field level, so the code has to do its own checks.

Secret

A key or password stored in the secrets vault, where only backend code can reach it. Never put one in front-end code.

created_by and created_by_id

Two fields on each record: the creator's email and the creator's id. Creator-based rules compare like with like.

Security scan

Base44's built-in check of your app. It lists findings by seriousness. Run it before you publish and after big changes.

API keygeneral

A password that lets code use a service, such as payments or email. Anyone holding it can use that service as you.

Webhookgeneral

An address another service calls to tell your app something happened, such as a payment. It has to be public, so your function must check the caller is who it claims to be.

Ask the AI chat

Paste these into your app's AI chat. They are our suggestions, not Base44's. The AI can miss things, so finish with the security scan.

  • Audit every table

    List every table in my app. For each one, tell me who can create, read, update and delete its records. Flag any table that holds personal data where Read is set to All Users. Do not change anything yet.

  • Audit every function

    Review every backend function in my app. For each one, tell me whether it checks who is calling, whether it runs as the service role, and whether it returns data without limiting it to the caller. List the ones that do not.

  • Find keys in the browser code

    Search my app's front-end code for API keys, tokens or passwords. List each one with the file it is in and the service it belongs to. Do not change anything yet, and do not print the secret values.

  • Review who can get in

    Tell me my app's visibility setting and list everyone invited, with their role. Point out anyone who has the Admin role and does not need it.

  • Preview recommendations before you apply

    Show me each permission recommendation as a before and after for the rule it would replace. Wait for me to say which ones to apply.

See all 24 prompts

Now put it to work

Play Level 8: the rule that matches nobody Build your checklist

Leak Hunt: checked against Base44's docs on 17 Oct 2026. Docs change, and the security scan is the authority.