Security testing for no-code and AI-built apps

If you built your product on Bubble, Supabase or Firebase, or with an AI coding tool, the platform handles the back end and your data rules live in settings. One wrong setting can expose a whole table.

What goes wrong on these platforms?#

The browser talks to the data layer directly, and anyone can send the same requests with a different account or with none. The rules on the data layer are therefore the security boundary.

What do the platform docs say?#

Bubble#

Privacy rules are "conditions you set up on each data type to protect your data from being viewed and edited by unauthorized users." Bubble describes them as additive: "you don't prohibit access, you grant it", and the user gets "the combined access of all matching rules, not the strictest one." The docs also say "Searches made through the Data API always need explicit permission", and warn that allowing a constraint on a field users cannot view "can expose that field's values through search inference." (Bubble Docs; see also the security checklist). Our guide to Bubble app security goes further.

Supabase#

The Supabase docs say a secret key "bypasses every Row Level Security policy you have", and to never put one "in a browser, a shipped application, or source control." A publishable key (the legacy anon key) is "safe to expose online" because it "only reaches what Row Level Security allows" (Supabase API keys). The RLS guide says to enable RLS on every table in an exposed schema (Supabase RLS). See Supabase security testing.

Firebase#

Firebase says that because clients reach data directly, "Firebase Security Rules are the only safeguard blocking access for malicious users", and warns that a deployed app "is publicly accessible, even if you haven't launched it." It does not recommend leaving data open to any signed-in user (Firebase rules basics). Read Firebase Security Rules testing.

How do we test these apps?#

We call the data APIs directly, as an attacker would: with an anonymous session, with user A and with user B. We list what each can read and write. We review the client JavaScript for keys, project IDs and hidden endpoints, then check what each key reaches.

A finding needs evidence of a real effect, so we prove a write by reading the record back through another session. We run controls beside each request (a nonexistent ID, a wrong record type, another account's token) and report the controls that held. See the methodology.

GET /rest/v1/profiles?select=email,plan&limit=2 HTTP/1.1
Host: demo-project.example.com
apikey: <publishable-key-from-bundle>

HTTP/1.1 200 OK
[{"email":"a@example.com","plan":"pro"},{"email":"b@example.com","plan":"free"}]

What do you get?#

You get a report in HTML, PDF and Markdown with proof-of-concept scripts, an executive summary, and a fix for each finding that names the platform setting to change. We can retest fixes; see retesting. If you are about to launch, read pre-launch security testing.

What do we need from you?#

• Written authorization from the system owner.
• The app URL and the platform in use.
• Test accounts for each role, at least two users.
• Optional: read-only access to privacy rules, RLS policies or Security Rules.
• A list of third-party services the app calls.
• A technical contact.

What changes the quote?#

The number of data types or tables, roles, workflows, API routes and integrations drives effort, and so does a retest. See pricing. We publish no prices.

For a small app, ask about the free pentest pilot, or request a pentest.