Security check for AI-built apps
Security check for AI-built apps: what a stranger's account can reach in yours.
With Lovable, Bolt, Cursor or v0, an app with a database, sign-in and file storage goes live in days rather than months. Whether a signed-in user sees only their own data is something your own testing never reveals, because there you only ever see yourself. Our security check tests exactly that: with two real test accounts and without signing in, against your running app on a Supabase or Firebase backend. Every finding comes with proof and a suggested fix, and once you have made your changes, a retest confirms the gap is closed.
- For founders and teams who built fast with AI tools and need confidence before a launch, an investor meeting or a customer conversation.
- At the core: your database access rules, tested with two accounts, plus secrets, storage, authentication, server functions and AI features.
- A manual review against your running app within a scope agreed in writing, not just a scanner run.
- A report with proof and a suggested fix per finding, readable without a security team, plus a retest.
Who the check is for
For founders and small teams who built an app with an AI tool, or had one built, and are now at one of these points:
- Before launch. Real users, real data, maybe payments already. You want to know whether the app holds up before someone else finds out.
- Before an investor meeting. Due diligence will ask how user data is protected. A report with evidenced findings and a retest is a better answer than "Lovable ran a scan".
- Before your first business customer. The customer sends a security questionnaire and asks for evidence of testing.
- After fast growth. The app grew one prompt at a time, and nobody on the team has ever read the access rules end to end.
Typical tools are Lovable, Bolt, Cursor, v0 or similar; typical backends are Supabase or Firebase. We clarify other combinations in the initial call.
Why AI-built apps need their own kind of test
With Supabase and Firebase, the public key is meant to ship in your frontend. What it can reach is decided by the access rules alone: Row Level Security policies in Supabase, Security Rules in Firebase. Both vendors say so in their documentation (Supabase, Firebase). If a rule is missing or too broad, anyone with the public key can get to the data.
AI tools build what you describe. What gets described is usually what the app should do, rarely what it must not do. A rule that is too broad produces no error, the app simply works. The platforms' built-in scanners are a good start, but they read code and configuration. Whether account B can actually reach account A's data only shows when someone tries. More on the mechanics in our guide to Lovable security issues.
What we test
Access rules with two accounts
Row Level Security or Security Rules on every table and collection: we create data as account A and try to read, change and delete it as account B and without signing in.
Keys and secrets in the frontend
Which keys sit in the JavaScript you ship, whether a secret or privileged key is among them, and whether third-party keys are exposed in the browser.
Storage buckets
Whether sensitive files sit in public buckets, whether contents can be listed, and whether a user can read, overwrite or delete someone else's files.
Authentication and accounts
Sign-up, password reset, email confirmation, sessions and roles: where a step can be skipped or an account taken over.
API endpoints and Edge Functions
Whether every server function checks who is calling and whether the record is theirs, including when it is called directly rather than through the app. Plus payment and unlock logic.
Permissions across tenants
When teams, companies or customers share one app: whether one tenant can reach another's data, invitations or actions, and whether roles can be self-promoted.
AI features and prompt injection
If your app uses AI itself: whether input or document content can steer the model into actions or data queries the user would not be allowed to perform.
The scope is set per project. What is tested, and what explicitly is not, is agreed in writing before testing begins. We only test systems you have engaged us to test in writing.
How the check works
Scope in writing
In the initial call we clarify which app, which environment and which features are in scope, and put scope, timeframe and rules of engagement in writing. Ideally we test a staging environment with realistic data.
Test accounts
You set up at least two accounts for us, and one per role or tenant if there are several. That is how we show what one account can reach in another.
Manual testing
We work against the running app and its API, not just the code. Tools help us collect, decisions are made by hand.
Proof per finding
Only what can be demonstrated with an executed proof is reported as a finding. Suspicions without evidence do not go into the report.
Report
An executive summary plus findings with rating, proof and a concrete suggested fix, written so you can paste it into your tool or hand it to your developers.
Retest
After your fixes we re-examine the resolved findings and document the state, so the remediation is evidenced.
What you get
- A written report with an executive summary for management, investors or customers.
- Per finding: description, rating, executed proof and a concrete suggested fix, such as the right policy or the missing check in a server function.
- A clear statement of what was tested and what was not.
- A retest of the resolved findings with the documented state.
See what that looks like in our sample report, based on a public finding.
Why CyberSec42
- Publicly verifiable. CVE-2026-15583 (Grafana MCP Server), CVE-2026-114123 (d365fo-mcp-server), CVE-2026-104776 (mcp-server-kubernetes), CVE-2026-110787 (pREST): reported under coordinated disclosure, fixed by the maintainers. See all findings
- See what your report looks like. Executive summary, finding with proof, retest: shown on a public finding. View the sample report
- We test behavior, not just code. Whether account B reaches account A's data shows when you try it against the running app.
- A proof per finding. Each reported finding comes with an executed proof. No reporting on suspicion.
- Honest framing. A clean result means no finding on what we tested, never a blanket guarantee.
Before real users arrive: have your app tested
In a free initial call we look at how your app is built, what data it handles and what scope makes sense for the check. You then receive a written fixed-price quote.
Request an app security checkCyberSec42 provides independent technical security testing. It is not an accredited certification body and does not provide legal advice. CyberSec42 is not affiliated with Lovable, Bolt, Cursor, v0, Supabase or Firebase.
Frequently asked questions
Isn't the platform's security scan enough?
Platform scanners are a good start and catch common mistakes such as missing access rules or open policies. But they read code and configuration. Whether the logic of your permissions holds, that is, whether a real second account can get to someone else's data, is not something they test with two real accounts. That is exactly what this check does.
How long does it take?
It depends on the scope: the number of roles, tables, server functions and integrations. We confirm the timeframe in writing after the initial call, together with the quote.
Do we have to share our code?
Not necessarily. The core of the test runs against the live app using test accounts. Read access to the code or the database configuration makes the review more thorough, especially for policies and server functions. What you share is agreed together in the scope.
What does it cost?
A fixed price per engagement, confirmed in writing after the initial call.
What if you find something?
Every finding comes with proof and a concrete suggested fix that you or your tool can implement. After your fixes we re-examine the resolved areas in a retest and document the state.