# Security testing for no-code and AI-built apps

Source: https://penetrationtestservices.com/no-code-app-security-testing/
Publisher: Excession Labs (penetrationtestservices.com)
Last updated: 2026-11-09

Security audit for Bubble, Supabase, Firebase and AI-built apps: privacy rules, RLS, Security Rules, exposed keys and workflow APIs, with a sample finding.

> **Short answer:** Apps built on Bubble, Supabase or Firebase, or with AI coding tools, keep their data rules in platform settings instead of server code. Failures to check include missing privacy rules, tables without row level security, open Firebase rules and secret keys in the browser. We test those rules from the outside with test accounts and report what an attacker can read or change.

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.

| Platform | What we test | Issue it finds |
|---|---|---|
| Bubble | Privacy rules, Data API and Workflow API settings, search constraints | A data type readable by anyone, or fields inferred through search |
| Supabase | RLS on every table, policies per role, storage policies, RPC functions, key use | A table readable or writable through the public API, or a service key in the browser |
| Firebase | Security Rules for Firestore, Realtime Database and Storage, auth checks in rules | Rules that let any visitor, or any signed-in user, read other users' data |
| Any, including AI-built | Keys and tokens in the client bundle, hidden routes, access control | Secrets in JavaScript, admin routes with no server check |

## 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](https://manual.bubble.io/help-guides/data/the-database/protecting-data-with-privacy-rules); see also the [security checklist](https://manual.bubble.io/help-guides/security/security-checklist)). Our guide to [Bubble app security](/guides/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](https://supabase.com/docs/guides/api/api-keys)). The RLS guide says to enable RLS on every table in an exposed schema ([Supabase RLS](https://supabase.com/docs/guides/database/postgres/row-level-security)). See [Supabase security testing](/guides/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](https://firebase.google.com/docs/rules/basics)). Read [Firebase Security Rules testing](/guides/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](/methodology/).

> **Sample finding:** This is a demonstration. It uses a fictional app, Harbor Notes, on a fictional Supabase project, and no real customer system was tested.
> 
> **Finding N-02: The `profiles` table is readable by any visitor (High).** RLS is not enabled on the table.
> 
> ```http
> GET /rest/v1/profiles?select=email,plan&limit=2 HTTP/1.1
> Host: demo-project.example.com
> apikey: 
> ```
> 
> ```http
> HTTP/1.1 200 OK
> [{"email":"a@example.com","plan":"pro"},{"email":"b@example.com","plan":"free"}]
> ```
> 
> Observed with no user session. Control: the `notes` table, which has RLS, returned an empty list for the same call. Fix: enable RLS on `profiles` and add a policy limited to the owner.
## 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](/retesting/). If you are about to launch, read [pre-launch security testing](/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](/pricing/). We publish no prices.

For a small app, ask about the [free pentest pilot](/free-pentest/), or [request a pentest](/contact/).

## Questions

### Is a Supabase anon key in my front-end code a problem?

Not by itself. Supabase says the publishable (formerly anon) key is safe to expose online, because it only reaches what Row Level Security allows. The risk is a table with no RLS policy, or a secret or service_role key in the browser.

### Do Bubble apps need a pentest?

Bubble runs the platform, but your privacy rules, workflows and API settings are yours. A test checks whether those settings protect your data from users who call the app directly.

### Can you test an app that an AI coding tool built?

Yes. We test the running app and API from the outside, as we test any app. AI-generated code is not a separate category for us. We look at access control, keys in client code, rules and configuration.

### Do you need access to my Supabase or Firebase console?

Not for the core test. Black-box and grey-box testing use test accounts. Read-only access to rules and policies speeds up the work and makes fixes more exact. Tell us at scoping what you can share.

## Sources

- [Bubble Docs: Protecting data with privacy rules](https://manual.bubble.io/help-guides/data/the-database/protecting-data-with-privacy-rules)
- [Bubble Docs: Security checklist](https://manual.bubble.io/help-guides/security/security-checklist)
- [Supabase Docs: Row Level Security](https://supabase.com/docs/guides/database/postgres/row-level-security)
- [Supabase Docs: Understanding API keys](https://supabase.com/docs/guides/api/api-keys)
- [Firebase Security Rules](https://firebase.google.com/docs/rules)
- [Firebase Security Rules: basics](https://firebase.google.com/docs/rules/basics)