Base44 App Penetration Testing

Every entity in a Base44 app carries its own row and field-level rules. A backend function can run with a service role that bypasses every one of them, so what is actually allowed depends on which path a request took.

The rule decides who can see a record, not the screen built on top of it

Base44 entities carry two independent security layers: Row Level Security (RLS), which controls which records a rule allows, and Field Level Security (FLS), which controls which properties inside those records a rule exposes. Base44’s own documentation defines a rule as a condition built from entity fields such as created_by, or a user_condition checking the caller’s role or a custom user field, combined with operators including $or, $and and $in. A denied list or filter call simply returns an empty result, while a denied get, create or update throws an error instead, and base44.asServiceRole bypasses both RLS and FLS entirely whenever it runs inside a backend function. We test the rule attached to every entity and every field against every role the app defines, and check where the service role is reachable from.

App visibility is a separate control from data permissions. Base44’s documentation on managing access sets out three levels: Public apps need no sign-in, Private apps require an invite or an SSO auto-admit rule, and Workspace apps open to every signed-in member of the workspace. It also states plainly that an app without login cannot identify who a visitor is, so a rule written against created_by or a signed-in role has no caller to compare against on a page nobody signed into. Every app starts with two built-in roles, Admin and User, and a builder can add further custom roles and custom user fields for a rule’s user_condition to check. We test each visibility level, each role and each custom field the app actually defines, rather than the two roles most apps start with.

Custom logic runs in Deno-powered backend functions, and Base44’s own security scan flags a function that returns data without checking the caller as one anyone can run, and separately flags API keys or tokens it finds somewhere an app visitor could reach. A shared connector attaches one account’s credential to the whole app, while an app-user connector issues each signed-in person their own token, and both are meant to be read inside a backend function with secrets.get() rather than held in code a visitor could load. Base44’s AI can write the fix for a flagged function, rule or dependency and apply it in a single click. We test what each function actually checks, what each credential can actually reach, and whether an AI-applied fix closed the real gap or only the symptom the scanner saw.