UBI

How to Secure an App You Built With AI (Even If You Can't Code)

By Marko, founder of UBI ยท October 22, 2026

AI coding tools like Claude, Cursor and Lovable will build you an app that works, but working and safe are different things, and the gap is usually invisible to the person who built it. This guide is for founders who can ship an app with AI but can't read its code. It walks through six checks you can run yourself by directing your coding agent, from finding exposed secrets to attacking your own app before someone else does.

I teach non-technical people to build with AI, and the advice here comes from conversations with security companies at Cloudflare Connect 2026, checked against the sources linked throughout.

Here's the short version:

  1. Keep secret keys out of anything that runs in a browser or on a phone.
  2. Lock down who can read your database.
  3. Make sure your server checks what each user is allowed to see.
  4. Test the running app, not just its code.
  5. Apply security updates to your platform and the components it uses.
  6. Retest every fix and keep a record.

If you only do one thing today, paste the prompt below into your coding agent. The rest of the guide explains each check and how to tell whether it worked.

Review this app for security risks before launch.

Identify privileged secrets in browser code, mobile bundles,
repositories, and deployed assets. Distinguish secrets from
identifiers that the provider explicitly intends to be public.

Check the database's access rules (for example Supabase row
level security or Firebase security rules) on every table, and
confirm that nothing is readable or writable by anyone who
isn't meant to have access.

Check that the server enforces permissions for customer data
and administrative actions. Use separate test accounts to
verify that one user cannot access another user's records.

Review dependencies and run appropriate static checks.
Propose dynamic tests against an authorized test environment
using synthetic data.

For each finding, report:
- The affected component
- The practical risk
- The proposed fix
- How the fix will be verified
- What remains untested

Do not include secret values in the report or describe the
app as secure solely because automated checks pass.

That last line matters, because a clean result only means nothing was found within that test's scope.

The quick answer: how do you secure an app built with AI?

Use a repeatable security workflow rather than trusting that the code is safe because it works. Keep privileged secrets out of browser and mobile app code. Enforce access permissions on the server. Update vulnerable components. Test both the code and the running app.

Ask your AI coding agent to document each finding, explain the fix, and show how it was retested. Replace any credentials that were already exposed, because moving a key doesn't cancel copies someone already took. Then repeat the relevant checks before every release.

Automated testing can uncover real problems. Still, apps that handle sensitive data or have complicated permissions may need a professional review on top.

Are vibe coded apps safe to launch?

"Vibe coding" means building software mostly by describing what you want to an AI and accepting what it produces. Are those apps safe to launch? Some are. Some aren't. And you can't tell from the outside, because a vulnerable app and a secure one often look identical to the person using them.

So the honest answer is this: a vibe coded app is ready to launch once it has been checked, not once it runs.

A working app still needs a security check

On the All-In Podcast, Ben Horowitz described a test run at a16z, the venture capital firm. One AI agent builds an app. A second AI agent then tries to attack it. According to Horowitz, the second agent usually finds vulnerabilities.

That's an anecdote, not a published study. I don't have numbers behind it, and you shouldn't read it as proof that every AI-built app is broken. But it matches what I heard at booth after booth. AI optimises for the thing you asked for. Ask for a booking page and you'll get one. Unless you ask, you may not get server-side permission checks, safe handling of keys, or up-to-date dependencies.

Here's my view. Security should live inside your workflow, so it's as little as possible something you have to remember. Founders are already juggling sales, support and product. A process that runs every time beats good intentions every time.

You're responsible even if AI wrote the code

One theme came up repeatedly in those conversations: businesses have a responsibility to protect their customers' data. Using AI to build the app doesn't hand that responsibility to the AI provider. It stays with you.

I'm not going to list specific laws or penalties here, because that depends on where you operate and what data you hold. Treat this guide as risk reduction, not legal compliance. If you collect sensitive data, talk to a qualified advisor.

Treat browser and mobile app code as public

If I could get one idea into every founder's head, it's this one. Anything you send to a user's browser or phone can be read.

Approov, a company that sells security for mobile apps and the APIs behind them, makes this point forcefully. An API, or application programming interface, is how your app talks to a server or an outside service. An API key is the password-like string that proves your app is allowed to make those calls.

Approov's argument is that authentication isn't the same as trust. Your app showing a valid key proves only that someone has the key. According to Approov, attackers get keys in two main ways:

The usual defence against interception is certificate pinning, where the app only trusts one specific server certificate. Approov says pinning can be bypassed. That doesn't make it useless; it raises the effort required. But it isn't a guarantee.

The practical takeaway is simple. Keep API keys, secrets and important logic on your server. Never put them in front-end code (the part that runs in the browser) or in the app bundle you ship to phones.

Not every "key" is a secret

One nuance before you panic. Some services deliberately issue keys that are meant to be public, and their documentation says so. Those are identifiers, not passwords. The ones to worry about are privileged secrets: anything that can spend money, read customer data, send email on your behalf, or change your database.

When in doubt, ask your agent to check the provider's documentation rather than guessing from the name.

Run these checks before you launch

This is the core of the guide. Each step comes with what to ask for and how to tell whether it worked.

1. Find exposed secrets and replace them

What to do: Ask your coding agent to search your browser code, mobile bundles, code repository and deployed files for privileged secrets. Any it finds should be moved to the server, so the browser asks your server to make the call instead of calling the outside service directly.

Why it matters: A key sitting in front-end code is a key anyone can copy.

Don't skip this part: If a secret was ever exposed, replace it in the provider's dashboard. That's called rotating or revoking the key. Moving it to the server stops future leaks; it doesn't cancel copies already taken.

How to tell it worked:

2. Lock down who can read your database

Many apps built with AI keep their data in a hosted database such as Supabase or Firebase, and the app in your customer's browser talks to that database directly. What stops a stranger from reading every row is a set of access rules on the database itself: row level security in Supabase, security rules in Firebase. If those rules are switched off or left wide open, anyone who finds your app's public database address can read or change the data, no hacking skills required.

What to do: Ask your coding agent to list every table, say whether access rules are switched on for each one, and explain in plain words who can read and write it.

How to tell it worked: Every table that holds customer data has rules switched on, and the agent can show you that a request made without logging in gets nothing back.

3. Check what each user is allowed to access

A login screen feels like protection. However, it answers only one question.

Authentication confirms who someone is. Authorization decides what they may see and do. Plenty of apps get the first right and the second wrong, so a logged-in customer can view another customer's orders just by changing a number in the address bar.

What to do: Create two test accounts with made-up data, say Customer A and Customer B. Ask your agent to confirm the server checks ownership on every request for customer records and every admin action. Then have it try to load Customer B's data while logged in as Customer A.

How to tell it worked: Each account sees only its own information. Admin pages and actions refuse ordinary users. And the checks happen on the server, not just by hiding buttons in the interface.

4. Test the running app as well as its code

There are two broad kinds of testing, and they catch different things.

Type of checkWhat it looks atGood at finding
Static analysisThe code itself, without running itHard-coded secrets, risky patterns, outdated libraries
Dynamic testingThe live, running app, poked like an attacker wouldBroken permissions, injection flaws, misconfigured servers

Use both where you can. In practice, that might mean asking a second agent to attack what the first one built, the same idea Horowitz described.

At StackHawk's booth I learned about Wingman. It lets an AI coding agent run dynamic, attack-style tests as well as static checks on the app it just built. In that conversation it was quoted at $10 a month; check the current pricing and limits before you sign up. StackHawk's flyer claims coding agents fixed more than 11,000 vulnerabilities in 100 days across 220+ teams. That's StackHawk's own number, not an independent measurement, but it shows the kind of workflow these tools aim for.

A safety rule: run attack-style tests only against an environment you own or are authorised to test, ideally a copy of your app filled with fake data.

How to tell it worked: You get a list of findings with severity, location and a proposed fix, plus a clear note on what the test didn't cover.

5. Apply relevant security updates

Your app sits on top of other software: a hosting platform, a programming language, libraries called dependencies, maybe a database. When a flaw is found in any of them, the fix only helps once it's installed.

October 20 to 21, 2026 showed how quickly this moves:

Does this mean your app is affected? Only if it uses those products and versions. The broader lesson is that serious flaws in widely used software appear often, and some can be exploited without any password at all.

What to do: Ask your agent to list every platform, framework and dependency your app uses, with version numbers. Then check them against known security fixes and update what's out of date.

How to tell it worked: The new version is actually deployed, not just changed in a file, and any needed restart has happened. If your host manages the platform, ask them to confirm.

6. Retest fixes and preserve the results

AI agents are confident. "Done, that's fixed!" is easy to type. You want evidence instead.

What to do: For every finding, keep a short record: what was found, what changed, how it was retested, and what still hasn't been tested. A shared document or a notes file in your repository is fine.

How to tell it worked: You can show someone else, say a future CTO or a security reviewer, what was checked and when.

Make these checks part of every release

Checklists you remember once a quarter don't protect anyone. Instead, build the checks into how you ship.

A simple setup for a solo founder:

  1. Before every release, run the security prompt at the top of this guide and a static scan.
  2. Before any change to logins, payments or customer data, repeat the two-account permissions test.
  3. Every month, ask your agent for a dependency and platform update report.
  4. When a major vulnerability makes the news, ask whether you use the affected product and version.
  5. Decide who owns it. If that's you, put it in your calendar. If it's a contractor, write it down.

You can also add instructions to your agent's standing rules file, so it avoids putting secrets in front-end code by default. The less you rely on memory, the better.

How a non-technical founder can check their website for security vulnerabilities

Let's be direct about what you can and can't do on your own.

You can direct your coding agent through the steps above, ask for evidence, run the two-account test yourself in a browser, and keep your platforms updated. You can also add a dedicated testing tool that runs attack-style checks.

What you can't easily do is judge whether a complex system is truly safe. That's where expert help comes in.

Know when to get expert help

Bring in a security professional when:

In that last case, act quickly. Rotate keys, check logs, and get help rather than waiting.

Frequently asked questions

Can I secure an AI-built app without learning to code?

You can direct many important checks without writing code, as long as you ask for evidence you can review. Your job is to make responsibility, verification and escalation explicit. How much professional help you need depends on the data you hold and what failure would cost.

If my app has a login screen, why could customer data still be exposed?

Logging in proves who someone is. It doesn't prove the server checks whether they own the record they're asking for. Use two test accounts: each should see only its own data.

Is moving API keys to the server enough?

It closes one route. Your server still needs to control how its endpoints are used, or someone can abuse them instead. Previously exposed keys also need rotating.

Can a second AI agent or a tool like Wingman prove my app is safe?

No tool proves safety. Extra testing can reveal what the builder missed, but coverage depends on setup and what the test actually exercises. Verify important findings and retest every fix.

Do the GitLab, PHP and Oracle vulnerabilities affect my app?

Only if your app or its infrastructure runs an affected product and version. Ask your agent or host to confirm, and check that any fix is actually deployed.

Who is responsible if AI wrote the code?

Your business is. Using AI doesn't transfer responsibility for protecting customer data.

Start with one concrete check

Don't try to do everything today. Start with the secrets check. It's the fastest win and often the most serious exposure.

Your pre-launch checklist:

Key takeaways

Once your app is locked down, check the rest of your site while you're at it. Paste your URL into UBI for a free scan of the things that decide whether customers find and trust it: SEO, AI search readiness, performance, accessibility, and how well AI agents can use your site. UBI then walks you or your coding agent through fixing what it finds. It doesn't run security tests, so the checks in this guide are still yours to run.

Sources