The security incidents that have defined the AI app era were not sophisticated attacks. In 2025, the Tea app exposed tens of thousands of user images, including photo IDs, through a storage bucket that was configured to be publicly readable. The same year, security researchers scanning apps built with AI tools found user data readable in a meaningful share of them, through database rules that were never turned on. Configuration, in every case. Which is good news, in a way: configuration can be checked, and this is the checklist.
Quick answer: Before launch, verify five things: no secrets in the client code or repo history, authentication enforced on the server for every route and endpoint, database rules that deny by default, storage buckets private unless deliberately public, and webhook signatures verified on payments. Most AI app breaches came from one of these, and each is checkable in minutes.
Why are AI-built apps a target?
Uniformity. Millions of apps now share near-identical stacks and near-identical default mistakes, which means attackers do not need to study your app, they scan for the pattern. Automated tools sweep published apps for open database endpoints, listable storage buckets, and keys in JavaScript bundles. Obscurity is not a defense when discovery is automated, and small apps get scanned with exactly the same enthusiasm as big ones.
What secrets end up in the code?
The classic finds: API keys pasted into frontend code where every visitor can read them, admin-level database keys used client-side because it made an error go away, and .env files committed to the repo in week one and forgotten. Two checks cover it. View your deployed app’s source and search the JavaScript bundle for key-shaped strings and words like secret and service. Then search your git history, because deleting a key from the current code does not remove it from the past. Anything found gets rotated, because removing it from the code leaves the copied key working.
Is your authentication real?
AI tools reliably build login screens. What they skip, often, is enforcement: the server-side check on every route, API endpoint, and function that the request is authenticated and authorized for that data. If protection means the interface does not show the button, there is no protection, because attackers do not use your interface. The test is blunt and takes five minutes: log out, then request your API endpoints directly with curl or the browser console, including endpoints for other users’ records. Everything that answers with data is a finding.
Are your database rules turned on?
This is the big one for the Supabase-backed stacks most AI builders use, and it is the exact gap the 2025 research kept finding: row level security disabled, or enabled with policies that allow everything. The Tea app lesson applies to storage the same way: buckets holding user uploads, verification photos, or documents must not be publicly listable. The database deserves its own article, and it has one coming in this series, but the pre-launch version is one test: as a logged-out client, and as user A, try to read user B’s rows and files. Denied is the only acceptable answer.
What about payments and personal data?
Three rules. Verify webhook signatures, so an attacker cannot forge a payment-succeeded message to your app; the payment providers all document this and AI-generated integrations regularly skip it. Store the minimum: if you do not keep card numbers or ID photos, you cannot leak them, and your payment provider exists so you do not have to. And check that every form and API call runs over HTTPS with no mixed-content warnings, which your browser will tell you for free.
What ongoing security does a live app need?
Launch-day clean is a snapshot. Dependencies age and acquire published vulnerabilities, so updates need a schedule. Keys should rotate when people or vendors leave. And someone should look at the logs occasionally, because failed-login storms and weird traffic patterns announce most trouble in advance. This is the recurring half of security, and it belongs to whoever runs your production support. The full production picture beyond security is in our production readiness guide, and if you would rather have professionals run this entire checklist against your app, that is the audit we do.
Frequently asked questions
My platform says it scans for security issues. Is that enough?
The scans are worth running and catch the loudest problems. They cannot know your intent: which data should be public, which role sees what, whether that admin route is supposed to exist. Configuration and business logic remain yours to verify.
What is the fastest self-check I can do today?
Two tests, ten minutes. Log out and request your API endpoints directly, looking for any that return data. Then view source on your deployed app and search the bundle for API keys. Those two checks would have prevented a remarkable share of documented incidents.
Is my public API key in the frontend a problem?
Depends on the key. Publishable keys (like Supabase’s anon key) are designed to be visible, and security comes from the database rules behind them. Admin, secret, or service-role keys must never ship to the client under any circumstances.
I found exposed data. What now?
Close the hole first, then rotate every key that could have been used, then assess what was reachable and for how long. Depending on your users and jurisdictions, disclosure may be a legal obligation, so this is the moment to involve professionals rather than hope.
Do small apps with few users get attacked?
Yes, because attackers scan patterns rather than reading traffic charts. An exposed bucket with 40 users’ documents is the same one-line find for a scanner as one with 40,000. Size buys you nothing.
Do I need a penetration test?
Eventually, maybe. First, the configuration audit, which is cheaper and catches the class of problem AI-built apps have. Formal penetration testing earns its cost once the basics are verified and the stakes (payments, sensitive data, compliance) justify it.