Exposed keys and secrets
API keys for payment, email, AI and database services that ended up in the browser code, the mobile app bundle or a public repository. Keys that are meant to be public are separated from the ones that must never be.
Secure Your AI-Built App
AI coding tools can take an idea to a working app in an afternoon. They are much less careful about who else can use it. We review what the tool built, find the keys, database rules and access checks that would let a stranger in, and give you fixes you can apply yourself, often by pasting them straight back into the same AI tool.
AI-Built App Security Review
What it is
A focused security review of a web or mobile app that was built, mostly or entirely, with an AI coding tool. We look at the running app from the outside, sign in with test accounts you provide, and read the code if you share it, then report the issues in plain language with a fix for each. It is a non-intrusive review done with your written authorisation, not a penetration test.
Why organisations need it
AI tools write code that works on the happy path. Security usually lives off it: whether a database table can be read by anyone holding the public key, whether a user can open another user's record by changing a number in the address bar, whether a secret key was shipped inside the website's own code. None of these show up when you click through the app yourself, and all of them are easy for someone else to find. If the app holds personal data, the PDPA's Security Principle applies to it like any other system, and a leak can trigger the breach notification duty.
What the engagement covers
Scoped to one app and its backend. Most reviews cover the six areas below; we tell you up front if something in your stack needs more.
Database access rules
For Supabase, whether Row Level Security is enabled and correct on every table, since the anon key in your app is public by design. For Firebase, whether security rules were left in test mode. Checked table by table, not assumed.
Login and access checks
Whether the server, not just the screen, decides who may see and change what. We test whether one user can read or edit another user's data, and whether admin functions are reachable by ordinary accounts.
Open endpoints and functions
API routes, serverless and edge functions, webhooks and file storage buckets that answer requests nobody should be making, including ones the AI created and the app no longer uses.
Dependencies and configuration
Outdated packages with known vulnerabilities, debug settings left on, overly broad CORS, missing security headers and error messages that reveal internals.
Personal data handling
What personal data the app collects, where it is stored and who can reach it, checked against the PDPA's Security Principle, with the privacy notice and consent points your launch will need.
What the business gets out of it
Find it before a stranger does
The issues that sink AI-built apps are usually simple and easy to discover. A review before launch, or right after, costs far less than cleaning up after someone else found them.
Fixes you can actually apply
Each finding comes with a plain explanation and a concrete fix, written so you can paste it into your AI tool or hand it to a developer, rather than a scanner report full of jargon.
Keep building fast
You do not have to stop using AI tools to be safe. You need to know which few things they tend to get wrong and check those every time. We leave you with that checklist.
Evidence for customers and investors
A short report showing the app was reviewed and the findings were fixed answers the security question in customer due diligence and investor conversations.
PDPA covered from the start
If the app holds personal data, the review doubles as your first Security Principle check, which is easier than retrofitting it after launch.
A re-check after you fix
We confirm the fixes worked, so you are not left guessing whether the AI's change actually closed the gap.
How it works
How the engagement runs
01
Scope and authorisation
You tell us the app, the platforms behind it and what it does. We agree the scope in writing, and you provide test accounts and, if you want a deeper review, read-only access to the code.
02
Outside-in review
We look at the running app the way a curious stranger would: the code it sends to the browser, the requests it makes and what those endpoints return.
03
Signed-in review
Using your test accounts, we check what each type of user can reach, and whether one user can get at another's data.
04
Backend and code review
Database rules, storage, functions and, where shared, the repository, looking for the patterns AI tools most often get wrong.
05
Report and fixes
Findings ranked by how easily they could be abused and what they would expose, each with a fix you or your AI tool can apply.
06
Re-check
Once you have applied the fixes, we test them again and update the report.
Deliverables
What you receive
Findings report
Each issue in plain language, ranked by risk, with where it is and what it would expose.
Fix instructions
A concrete fix per finding, written to paste into your AI tool or hand to a developer.
Database rules review
Table-by-table result for Supabase Row Level Security or Firebase rules, with corrected policies where needed.
Secrets list
Every key found, which must be rotated, and where each one should live instead.
Launch checklist
The short list of checks to repeat whenever the AI tool changes your app.
Re-check confirmation
Confirmation that the fixes were applied and worked, for your records and your customers.
Who it is for
Who this is built for
Industries
Company sizes
Departments
FAQ
FAQ
No. It is a non-intrusive review done with your written authorisation: we look at the running app, test with the accounts you give us, and read the code if you share it. We do not attempt to break or overload your systems.
Apps built with tools such as Lovable, Bolt, v0, Replit and Cursor, usually on backends such as Supabase or Firebase, and deployed on services such as Vercel or Netlify. If your stack is different, tell us and we will confirm before you commit.
Not by itself. It is designed to be public. What protects your data is Row Level Security on every table. If a table has RLS off or a policy that is too broad, anyone holding that public key can read or change it, which is exactly what we check.
We give you a concrete fix for each finding, written so you can paste it into your AI tool or pass it to a developer, and we re-check once it is applied. If you want us to coordinate with your developer, we can.
No, but it helps. The outside-in and signed-in reviews work without it. Read-only access to the repository lets us find issues that are not visible from outside, such as secrets in the code history.
If the app collects personal data in a commercial context, yes. Size does not exempt it. The review covers the Security Principle, and we flag the notice and consent points you will need.
For a typical single app, a few working days from receiving the test accounts, plus the re-check once your fixes are in.