Is my AI-built app secure? A 15-minute check
Six checks for an app built with Newly or another AI builder. Each one ends as detected, unknown or confirmed by owner evidence.
Founder, Newly
Published Last updated
Nobody can give you a one-word answer, and no AI builder can promise one. What you can do in 15 minutes is check the six places to look first: keys in the app bundle, open database rules, routes without auth, the chat feature, outdated runtimes and the website in front of the app. Mark each one detected, unknown or confirmed by owner evidence.
What does an AI builder handle for you, and what is left to you?
An AI builder writes code and runs the machinery that turns it into an app. Newly, for example, builds a real React Native and Expo app, and you can download the code or connect your own repository. That makes the project yours, decisions included: which tables exist, who may read them, which keys ship inside the app, and what your AI features are allowed to do.
A builder's platform measures protect the platform. They do not change a policy you wrote, rotate a key you exposed, or update a runtime on a server you run yourself. Those sit with you, and they are where the checks below look.
This is no verdict on AI-written code. Code you did not read is code you know less about, so the checks look at what the app ships and what its servers allow, whoever wrote it.
What is the 15-minute check?
Six checks, two to three minutes each. Write down what you find as you go. The self-test further down turns your notes into a list of what is detected, what is unknown and what you can prove.
1. Are there secret keys in the app bundle? (3 minutes)
Anything compiled into a mobile app or a web bundle can be read by anyone who downloads it. In an Expo project, every environment variable whose name starts with EXPO_PUBLIC_ is written into the JavaScript bundle. Open your .env files and app config and list every key.
Some keys are public by design, such as a Supabase anon or publishable key and a Stripe publishable key. Others must never ship: a Supabase service role key, a Stripe secret key, an AI provider's API key. If a secret key was ever in the app, rotate it. Deleting it from the code leaves it in every build people already installed and in your repository history.
2. Can anyone read your database? (3 minutes)
If your app uses Supabase, the public key inside the app lets anyone who has the app call your database API. Row level security (RLS) decides which rows each person can read and write. In the Supabase dashboard, open each table, confirm RLS is enabled, and read every policy. A policy whose condition is simply true lets everyone through, which leaves the table as open as no rule at all. Firebase and other backends have their own rules; check them the same way.
3. Does every route check who is asking? (3 minutes)
Hiding a button in the app does not stop anyone calling the endpoint behind it. Every server function, API route or edge function that returns or changes user data has to check on the server who is asking and whether they are allowed. Test it with two test accounts: sign in as the second and request something that belongs to the first. If it comes back, mark it detected. OWASP's Mobile Top 10 lists authentication and authorization failures as M3.
4. Can someone talk your chat feature into misbehaving? (2 minutes)
If your app has an AI chat or assistant, the model treats what users type as instructions, and it can treat text it reads, such as a pasted document or a web page, the same way. That is prompt injection, and no prompt wording fully prevents it. Limit what a successful injection can reach instead:
- Keep secrets out of the system prompt. Assume a user can make the model repeat it.
- Give the model's tools no more access than the signed-in user already has.
- Limit messages per user. AI inside a Newly app uses credits, and an endpoint anyone can call lets a stranger spend them.
5. Are your runtimes and dependencies patched? (2 minutes)
The app on the phone runs neither Node.js nor PHP. Your build machine, your server code and the website that promotes the app might. On October 21, 2026, Node.js shipped security releases for a Brotli decoder flaw that can allow remote code execution (CVE-2026-111497), two TLS hostname-check bypasses and a certificate-validation issue. Run node --version where Node actually runs, including CI runners and container images, and update to the fixed release of your major line. Then run npm audit in the project and read what it reports.
The same day, PHP disclosed PHP2Shell: two flaws (CVE-2026-109618 and CVE-2026-109619) that can allow remote code execution without logging in. The table below has the fixed versions for both runtimes.
6. What about the website in front of the app? (2 minutes)
Your landing page, store or blog is often a separate system with its own software, plugins and admin login. WordPress, WooCommerce, Drupal and Laravel sites run on PHP, so PHP2Shell applies to them. Ask your host which PHP version serves the site. php -v on the command line can report a different PHP from the one answering web requests, and distribution packages can backport fixes under an older version number. While you are there, open /.env and /.git/config on your domain in a browser. A 404 is what you want to see.
Which versions fix the October 2026 runtime flaws?
| Software | What was fixed | Fixed versions | Where to check |
|---|---|---|---|
| Node.js | Brotli RCE (CVE-2026-111497), two TLS hostname bypasses, one certificate-validation issue | 22.23.4 / 24.22.1 / 26.12.1 | node --version on servers, build machines and container images |
| PHP (PHP2Shell) | CVE-2026-109618 and CVE-2026-109619, unauthenticated RCE, CVSS 9.2 | 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35 | Ask your host which PHP serves web requests, and whether a backported fix applies |
Reading this table
Versions are from the Node.js and PHP security notices of October 21, 2026. PHP 8.1 and older no longer get routine updates from the PHP project. A version number read from outside is a hint about patch state; on its own it does not prove the fix is in place.
Where do you stand?
Mark each item. Everything starts as unknown, because that is what an unchecked item is. Move an item to confirmed only when you hold the evidence listed under it.
Your 15-minute check
- Detected: You found the problem.
- Unknown: Not checked yet, or the check could not tell.
- Confirmed by owner evidence: You checked and kept the proof.
Your answers stay in this browser tab. Nothing is saved or sent.
Frequently asked questions
Is code written by AI riskier than code written by hand?
There is no reliable general answer. What changes is that you may not have read the code, so you know less about what it does. The checks on this page work the same either way: they look at what the app ships and what its servers allow, whoever wrote it.
Does a clean scan mean my app has no vulnerabilities?
No. A scan reports what it detected from where it looked. A version-matching scan can say a version is affected but cannot tell whether your setup is exposed, and it cannot see a fix your host backported or code that never answers a public request. Treat a clean result as unknown until you have owner evidence.
I removed a leaked key from my code. Am I done?
Rotate it as well. Removing the key from the code leaves it in every build people already installed, in your repository history, and with anyone who already copied it. Create a new key, switch the app or server to it, then revoke the old one.
Do the October 2026 Node.js and PHP fixes matter if I only have a mobile app?
The app on the phone runs neither. Your build machine, any server code and the website that promotes the app might. Run node --version wherever Node runs and ask your host which PHP version serves your website.
Sources
- PHP security notice, October 21, 2026, php.net
- October 21, 2026 security releases, nodejs.org
- OWASP Mobile Top 10, OWASP Foundation
- Row Level Security, Supabase docs
- Environment variables in Expo, Expo docs