Secure Your AI-Built App Before Launch: 2026 Checklist

A practical, non-technical checklist for shipping an AI-built app without getting breached in week one.

A scan of 380,000 apps built on AI coding platforms found roughly 5,000 leaking sensitive corporate or personal data in plain sight - Security Boulevard. No hackers required. No exploit needed. The data was just sitting there, publicly reachable, because nobody had checked whether it was locked down before the app went live.

Here is the problem: the tools that let you build a working app in an afternoon were never designed to stop there. They optimize for one thing, getting the demo to run, and security is not part of that optimization target. A founder using Founden, Lovable, bolt.new, Replit Agent, v0, Base44, Cursor, or Claude Code can go from idea to a live, working product faster than at any point in software history. What that speed does not include, by default, is the set of decisions a security-literate engineer would have made along the way: whether the database trusts every visitor, whether the API keys are sitting in a public GitHub repository, whether the admin panel checks who is knocking before it opens the door.

This guide is the checklist for closing that gap before launch, written for someone who does not know what SAST, DAST, RLS, or CORS mean yet and does not need to. It covers what actually goes wrong in AI-built apps in 2026, backed by real incidents and research, and it tells you exactly what to check, what to fix, and what a platform like Founden already handles for you versus what stays your job no matter which tool you built with.

Contents

1. Why "It Works" Is Not "It's Safe": The Structural Break in Code Review
2. The 2026 Track Record: What Actually Went Wrong
3. Secrets Management: Getting Keys Out of Your Code
4. Authentication and Authorization: Default-Deny, Not Default-Open
5. Database Security: Row-Level Security and Least-Privilege Roles
6. Dependency and Supply-Chain Security
7. API Security: Rate Limiting, CORS, Input Validation, and IDOR
8. Infrastructure: HTTPS, WAF, DDoS Protection, and Environment Separation
9. If Your App Talks to an LLM: Prompt Injection and Agentic Risk
10. Monitoring and Incident Response
11. Compliance Basics: GDPR, CCPA, and SOC 2
12. The Pre-Launch Pentest and Bug Bounty Question
13. Where the Platform Should Carry the Load vs Where You Still Own It
14. The 2026 Pre-Launch Security Checklist, Assembled

Before the section-by-section breakdown, here is how the major AI app-building platforms actually compare on the security dimension specifically, not on how good the generated UI looks or how fast the agent writes code. This is scored on what happens to security by default, not on capability.

How to read this table: the criteria are not "which tool is best," they are "what does the tool do to your security posture the moment you hit publish, before you have configured anything." Access control defaults (30% weight, the heaviest, because broken access control causes most real breaches) asks whether the platform adds any gate at all. Data and DB isolation (25%) asks whether your database trusts the internet by default. Secrets and dependency hygiene (20%) asks whether the platform catches a leaked key before it ships. Infra and deployment security (15%) covers HTTPS, environment separation, and hosting posture. Ongoing security tooling (10%) is whether anything keeps checking after launch, not just at the first publish. No platform here, including Founden, clears the bar on its own. Every row still needs the checklist in this guide applied on top, which is the entire point of what follows.

1. Why "It Works" Is Not "It's Safe": The Structural Break in Code Review

Software has always shipped with bugs, and security vulnerabilities are not new to 2026. What changed is not that AI writes worse code than a careless junior developer would. What changed is who is sitting in the seat that used to catch the mistake before it reached production. For thirty years, the standard software workflow put a human between "code exists" and "code ships": a pull request, a reviewer, a second set of eyes that asked "does this handle the case where the user is not who they say they are." That checkpoint was never perfect, but it existed, and it caught a meaningful share of exactly the mistakes this guide is about.

Vibe coding, the practice of describing what you want in plain language and accepting what the AI writes back, removes that checkpoint structurally, not accidentally. Sonar's 2026 developer survey of over 1,100 engineers found that 96% do not fully trust AI-generated code, yet only 48% consistently review it before committing it - Sonar. That gap between distrust and verification exists among professional developers who already know what a SQL injection looks like. For the 80% of people building on Lovable who self-identify as non-technical, founders, freelancers, and operators rather than engineers, reviewing generated code for a missing access check is not a matter of discipline, it is a skill they were never asked to have in the first place - Lovable. The reviewer did not get lazy. The reviewer was never in the loop to begin with.

This is the root cause, not a symptom of any specific tool. Every downstream problem in this guide, the exposed database, the hardcoded API key, the admin panel with no password, traces back to the same structural fact: the entity writing the code (the model) does not carry the professional liability, customer trust, or regulatory exposure of shipping it, and the entity that does carry that exposure (the founder) frequently cannot read the code well enough to catch what is wrong with it. Veracode's 2026 GenAI Code Security Report, which has tracked over 100 models across four testing snapshots since the program began, found the average security pass rate sitting at 56%, essentially unchanged from the year before despite the models themselves getting dramatically more capable at everything else - Veracode. Capability and security are not the same axis, and nothing about a model getting better at reasoning automatically makes it better at remembering to check who is allowed to delete a row.

The pattern in that chart matters more than any single number: models have gotten reasonably good at the vulnerability classes that show up constantly in training data and have decades of "here is the fix" tutorials attached (SQL injection, weak cryptography), and they remain bad at the classes that require reasoning about what happens to output after the model's job is technically done (cross-site scripting, log injection). Georgia Tech's Systems Software and Security Lab has been tracking this directly through its Vibe Security Radar project, which traces public CVE disclosures back to the AI-generated commit that introduced them. The tracker went from 6 confirmed AI-linked CVEs in January 2026 to 35 in March, and the lead researcher estimates the true number is five to ten times higher because most AI-assisted commits lack the metadata needed to trace them back to their origin - Georgia Tech.

Understanding this as a structural gap rather than a tooling problem changes how you should think about the rest of this guide. You are not looking for "the one setting that fixes AI code security." You are rebuilding, deliberately and by hand or with dedicated tools, the review checkpoint that used to happen automatically because a second engineer was reading every line. Founden and platforms like it can absorb some of that checkpoint into the platform itself (see section 13), but no platform can absorb the part of the checkpoint that requires a human decision about what data your specific app should expose to whom. That part is yours, every time, regardless of which tool wrote the code.

2. The 2026 Track Record: What Actually Went Wrong

Abstract risk is easy to dismiss. Specific, dated, named incidents are harder to wave away, so this section is deliberately concrete. The pattern across every incident below is the same: not a sophisticated attack, but a door that was never closed.

The clearest single case study is Baudr, a social network built entirely with AI tools by an Italian streamer for roughly 40 euros and launched live on Twitch on March 14, 2026 in front of thousands of viewers - DEV Community. Within hours, someone typed /admin into the browser address bar and reached a fully functional administration panel with no login screen, no password, and no access check of any kind. Thousands of user accounts were deleted in bulk, including the creator's own, and personal data was downloaded by people who had no business seeing it. A subsequent security review identified nine separate critical issues in the app's architecture. This was not an edge case; it was the default output of the build process, discovered by whoever tried the most obvious URL first.

Baudr is not an isolated anecdote. RedAccess, an Israeli cybersecurity firm, scanned 380,000 publicly accessible applications, databases, and related infrastructure built on Lovable, Base44, Replit, and the deployment platform Netlify, and found roughly 5,000 exposing genuinely sensitive data: patient records, financial statements, internal corporate strategy documents, and customer chat transcripts - Security Boulevard. Verified exposures in that dataset included a shipping company's vessel schedules, the status of confidential UK clinical trials at a healthcare firm, internal financials from a Brazilian bank, and customer chat logs from a British furniture retailer, plus a set of phishing sites built on the same tooling that impersonated Bank of America, FedEx, and McDonald's - VentureBeat. The root cause across nearly all of them was the same: several of these platforms default a new project to publicly accessible, and a founder who has never had to think about "who can see this URL" simply never flips the switch.

The database layer specifically deserves its own callout, because it is where the most damage concentrates. Supabase, the Postgres-as-a-service backend that many AI builders default to, ships with an opt-in security model called row-level security (covered in depth in section 5). When it is left off, and it was left off by default in a large share of apps generated by at least one major platform in 2025, every visitor with the app's public API key can read and write every row in every table, regardless of what the login screen implies - Braingrid. Lovable confirmed in mid-2025 that more than 170 production applications built on its platform had been shipped with Supabase row-level security completely disabled, a defect serious enough that the company subsequently built and shipped a pre-publish security scan specifically to catch it going forward - Superblocks. The company's own June 2026 announcement of that scanner is a useful signal in itself: platforms are visibly reacting to their own incident history, which means the incident history is real and the fixes are recent enough that you cannot assume every app built even a year earlier got the benefit of them.

Supply chain attacks compound the picture beyond application code, because they target the packages every app depends on rather than the app itself. In late August 2025, attackers compromised an npm publishing token belonging to a maintainer of Nx, a build tool used by roughly 4.6 million downloads a week, and released malicious versions that scanned developer machines for SSH keys, cloud credentials, and crypto wallets, then specifically abused installed AI CLI tools including Claude, Gemini, and Amazon Q to reconnoiter the victim's filesystem before exfiltrating the results to attacker-controlled GitHub repositories - The Hacker News. Researchers later traced more than 1,000 victim accounts where this exfiltration repository pattern appeared - Socket. This was one of the first documented supply chain attacks to deliberately weaponize the AI coding assistants sitting on the same machine as the compromised package, using them as reconnaissance tools against their own user - Endor Labs.

The npm ecosystem absorbed a second, larger wave shortly after. A self-propagating worm named Shai-Hulud first appeared in September 2025 and, once it compromised a maintainer's publishing credentials, automatically queried every package that maintainer had rights to, injected a malicious install hook, and republished a new version, spreading with no further attacker involvement required - CISA. A second wave in November 2025 compromised over 700 packages and generated more than 27,000 malicious GitHub repositories - Upwind. The campaign resurfaced again in August 2026 targeting the maintainer of keyv, a widely used key-value storage library, using a new variant called CHAINDROP - Elastic Security Labs. None of these attacks required the victim founder to make a mistake. They required the founder to run npm install on a normal day, which every AI-built app does by definition.

A newer and more specifically AI-shaped supply chain risk sits on top of both: slopsquatting, where an AI coding agent hallucinates a plausible but nonexistent package name and an attacker registers that exact name with malware inside it. Security researcher Charlie Eriksen documented one instance, react-codeshift, that AI coding tools had already caused to be installed in 237 code projects before anyone noticed the package did not actually exist - Aikido Security. A related campaign in August 2026, tracked as WEL1DROPPER, published nearly 800 malicious packages targeting exactly this hallucination pattern, a figure researchers say has since grown past 1,000 - Cloud Security Alliance. The mechanism only exists because AI agents install packages with far less friction than a human typing a command and pausing to think "wait, is that really the package name."

Taken together, these incidents are not a cherry-picked worst-case list. They are the visible tip of a pattern that Apiiro's research inside Fortune 50 engineering organizations quantifies at scale: teams using AI coding assistants commit code three to four times faster than their peers, while monthly security findings in the same codebases rose from roughly 1,000 to over 10,000 in six months, a tenfold increase, with privilege escalation paths specifically up 322% - Apiiro. Speed and risk are rising together, and the rest of this guide is the set of concrete steps that keeps your launch out of the next version of this section.

3. Secrets Management: Getting Keys Out of Your Code

A "secret" in this context is anything that grants access if someone else obtains it: an API key for Stripe or OpenAI, a database password, a signing key for user sessions, a service account credential for your hosting provider. The single most common way secrets leak from AI-built apps is also the simplest to picture: the AI writes the key directly into a file, that file gets committed to a public GitHub repository or shipped to the browser, and a bot finds it within minutes.

This is not a hypothetical failure mode, it is measured and it is large. GitGuardian's State of Secrets Sprawl 2026 report, which analyzes billions of commits across public GitHub, found 29 million new hardcoded secrets added to public repositories in 2025 alone, a 34% year-over-year increase and the largest single-year jump the firm has recorded - GitGuardian. The AI angle within that number is specific and growing: leaked secrets tied to AI services themselves rose 81% year over year, commits co-authored by AI coding tools leak secrets at roughly double the platform-wide baseline rate, and the newly popular Model Context Protocol (MCP), which lets AI agents call external tools, already accounts for over 24,000 unique leaked secrets found sitting in plain-text configuration files, a category that barely existed two years earlier - The Hacker News. If your app or an internal tool you built exposes an MCP server, its configuration deserves the exact same secret-scanning scrutiny as your source code, not less, because it is currently leaking at a higher rate.

Vercel's own security team published data from the launch check built into their v0 AI builder that makes the scale concrete from a single vendor's vantage point: the check has blocked over 100,000 insecure deployments since launch, including more than 17,000 in a single recent month for exposed secrets alone. The most common leaked keys were for Google Maps, reCAPTCHA, Supabase, and, notably, over a thousand instances of people about to ship their own OpenAI, Gemini, Claude, or xAI API keys directly into a public deployment - Vercel. A recurring root cause in Next.js apps specifically is the NEXT_PUBLIC_ environment variable prefix, which is designed to expose a variable to the browser on purpose (for things like a public analytics ID), but which an AI agent will sometimes use for a genuine secret because the variable "worked" during a quick local test.

Fixing this does not require becoming a security engineer. The first and highest-leverage step is a secret scanner run before every deployment, not after. Gitleaks is free, open-source, and runs as a pre-commit hook or a CI step that blocks a commit before it ever reaches a shared repository - Gitleaks vs TruffleHog comparison. TruffleHog, also free under an open license, goes a step further by actually testing whether a detected credential is still live, which cuts down on false positives that would otherwise train you to ignore the tool's warnings - same source. GitHub's own secret scanning and push protection now runs automatically on every public repository at no cost and can be enabled on private repositories through GitHub's Secret Protection add-on, priced at $19 per active committer per month - GitHub. Push protection specifically blocks the commit at the moment you try to push it, rather than flagging it after the fact, which is the difference between a secret that never reaches history and one that has to be rotated after the fact because git history is effectively permanent.

Beyond scanning, the structural fix is where secrets live in the first place. Every secret belongs in an environment variable manager provided by your hosting platform (Vercel, Render, Railway, or your own host's secret store), never in a file that gets committed to version control, and never in a value read directly by frontend JavaScript. Replit's Secrets manager is a reasonable reference model here: keys are encrypted at rest, hidden from the code editor and forked copies of a project, excluded from version history, and available identically in both development and the deployed environment so there is no reason to ever hardcode a fallback - Replit. If you are using Founden, environment configuration and third-party API keys for the products it provisions (billing, email, integrations) run through the platform's own managed deployment pipeline rather than a file a founder has to remember to .gitignore, which removes the single most common leak vector by construction rather than by discipline.

A practical five-minute check before every launch: search your entire repository, including old commits, for the literal strings sk-, AKIA, api_key, and your database connection string, because AI agents reuse these patterns constantly and a human search often catches what an automated scanner configured for a different pattern set misses. Follow that with a rotation of every key the AI has ever seen during development, even ones you believe never left your machine, because you cannot prove a negative about what a coding agent logged, cached, or sent to a third-party inference provider during the build process. Treat every key generated before your first security pass as potentially compromised, and generate fresh ones as the very last step before you flip your app to public.

4. Authentication and Authorization: Default-Deny, Not Default-Open

Authentication answers "who is this person." Authorization answers "what is this person allowed to do." AI-built apps get the first one right more often than the second, because a login screen is visually obvious and easy to prompt for, while the authorization check behind every individual button, API call, and database query is invisible in the UI and easy for both the founder and the model to forget to ask for.

The Baudr admin panel from section 2 is the purest example of an authentication failure: there was no login screen at all in front of a page that could delete every user in the system. But the more common and more insidious failure in 2026 is the authorization gap that hides behind a login screen that works perfectly well. A user logs in successfully, the app correctly confirms they are who they say they are, and then a specific API endpoint fails to check whether this logged-in user is allowed to see this specific piece of data, only that they are logged in as someone. Base44, the AI app builder acquired by Wix, shipped exactly this shape of bug: two authentication API endpoints, for registration and one-time-password verification, worked correctly for the app's intended users but never checked whether the app itself was supposed to be private, so anyone who knew the app's public ID (visible in every app's URL and manifest file) could register a brand-new, fully verified account into someone else's SSO-only enterprise application - Wiz. Wiz Research reported the flaw on July 9, 2025, and Wix shipped a fix within 24 hours, a genuinely fast turnaround that limited real-world exploitation, but the bug itself required only "basic API knowledge" to find and exploit, which is precisely the bar that makes it dangerous at scale rather than a sophisticated targeted attack - The Hacker News.

The principle that fixes both shapes of failure is the same one security engineers call default-deny: every route, every API endpoint, and every database query should start from "nobody is allowed to do this" and have access explicitly granted from there, rather than starting open and hoping someone remembers to lock specific things down later. AI coding agents, prompted casually, tend to build the opposite: a working feature first, with access control treated as a follow-up task that a non-technical founder does not know to ask for and the agent does not volunteer unprompted. If you are choosing an authentication provider rather than hand-rolling one, our deeper comparison of Clerk vs Better Auth covers the tooling trade-offs in depth; this section focuses specifically on the security posture questions that matter regardless of which provider you pick.

Before you launch, walk through every page and API route your app has and ask, for each one, three questions in order: does it require login at all, does it check that the logged-in user owns the specific resource being requested (a document ID, an order number, a user profile), and does it check the user's role if the app has more than one tier of access (a regular user versus an admin). A route that returns /api/orders/12 for a logged-in user needs to verify that order 12 actually belongs to that user, not just that some user is logged in; incrementing the number in the URL and seeing another customer's order is one of the single most common bugs found in AI-generated apps, and it has a name (insecure direct object reference, covered further in section 7).

For managed authentication rather than building your own session and password logic from scratch, the two most commonly recommended providers in 2026 are Auth0, priced free up to 25,000 monthly active users and from $35/month for the Essentials consumer tier beyond that, and Clerk, free up to 50,000 monthly retained users with a Pro tier at $25/month that includes one enterprise SSO connection. WorkOS takes a different pricing shape: user management (AuthKit) is free up to one million monthly active users, but a single enterprise SSO connection costs $125/month, roughly five times Clerk's equivalent, which matters if your customers are consumers now but might include enterprise buyers with SSO requirements later - WorkOS. Each of these providers defaults to secure session handling, password hashing, and multi-factor authentication out of the box, which removes an entire category of mistake an AI agent would otherwise have to get right from scratch every single time you ask it to add a login feature.

The most important behavior to verify manually, regardless of provider, is what happens when an unauthenticated request hits a protected route directly, bypassing the UI entirely. Open your browser's developer tools, find the network request your app makes when you load a protected page, and replay that exact request in a tool like curl or Postman without your session cookie or auth token attached. If the server still returns real data, your authorization is happening in the frontend (which any user can simply not run) rather than the backend (which they cannot bypass), and that gap is invisible in normal use because you, the founder, are always logged in when you test your own app.

5. Database Security: Row-Level Security and Least-Privilege Roles

Your database is where the actual damage lives. A leaked API key is bad; a database that hands every row to anyone who asks is the difference between an inconvenience and a headline. This section covers the two database-layer controls that matter most for an AI-built app: row-level security, and least-privilege service accounts, both of which are invisible in a working demo and both of which are frequently absent from what an AI agent generates unless specifically instructed.

Row-level security (RLS), most commonly discussed in the context of Supabase, the Postgres-as-a-service backend that a large share of AI builders default to, is a database feature that enforces authorization rules inside the database itself rather than trusting the application code to enforce them correctly every time. Without RLS enabled, any client holding the app's public API key (which is visible in the browser's network tab on every page load, by design) can read and, depending on configuration, write every row in every table, completely independent of whatever the app's login screen and UI suggest is protected. With RLS enabled and configured, Postgres itself refuses a query that tries to read a row the requesting user does not own, even if a bug elsewhere in the application would have otherwise allowed it through. This is why RLS is described as defense-in-depth: it is the backstop that catches the authorization mistake described in section 4 even after it has already happened in the application layer. Enabling RLS defaults every table to deny-all until you add explicit policies, which is the correct default but a genuinely surprising one to a founder who expected data to keep working the same way it did during development - Supabase documentation.

The scale of this specific gap in 2026 is well documented and consistent across independent sources. One analysis found that 11% of indie launch URLs expose Supabase credentials directly in frontend code, and that with the anonymous key exposed and RLS off, any visitor can read and write every row without ever needing to log in - Nurbak. Lovable's confirmed incident of 170+ exposed production applications, discussed in section 2, traces to exactly this gap - Superblocks. Bolt.new ships one specific protection (Prevent Leaked Passwords) turned on by default for new databases, but the recurring RLS-off pattern still shows up once a founder connects their own Supabase project rather than using Bolt's default database - vibe-eval. The takeaway is not "avoid Supabase," which remains a reasonable and widely used choice; it is that RLS is opt-in by design in Postgres, and an AI agent asked to "add a database" has no reason to opt you in unless the prompt or the platform explicitly does it for you.

If your app does not use Supabase, the equivalent concept still applies to any relational database: the account or credential your application server uses to talk to the database should never be the database's superuser or root account. Least-privilege database roles mean creating a dedicated service account for your application with permissions scoped to exactly the tables and operations (select, insert, update) it actually needs, and reserving the superuser credential for manual administration only, never for the running application - Crunchy Data. The practical benefit is containment: if your application server is compromised through some other vulnerability (a dependency flaw, a leaked key), the blast radius is limited to what that scoped role can touch, rather than the entire database including tables the compromised code was never supposed to reach.

Before you consider your database launch-ready, run through the following check on every table that stores user data, one table at a time rather than assuming a single global setting covers everything: confirm RLS (or your database's equivalent row-level authorization mechanism) is explicitly enabled, confirm a policy exists that scopes reads and writes to the requesting user's own rows, confirm the service role or superuser key never appears in any code that runs in the browser, confirm join tables and secondary tables (not just the main "users" table) carry the same policies, and confirm any file storage buckets attached to the database (profile photos, uploaded documents) have equivalent access rules rather than being left world-readable by default. This is a genuinely tedious pass through every table, and it is exactly the kind of tedious, unglamorous work an AI agent will not volunteer to do unless you ask for it explicitly, because it produces no visible change to the demo you are looking at.

Choosing the right database up front also reduces how much of this you have to retrofit later. Our deeper comparison of the best databases for your product and our guide to why AI apps corrupt data and the fix both cover adjacent failure modes worth reading alongside this section, since data integrity and data access control tend to break for related reasons in AI-generated backends. If your product genuinely serves multiple customer organizations from one shared database, our guide to building a multi-tenant SaaS app goes deeper into the tenant-isolation patterns that RLS alone does not fully solve, because multi-tenant isolation has to hold at the application layer too, not just the row layer.

6. Dependency and Supply-Chain Security

Every app you build with an AI tool pulls in dozens to hundreds of third-party packages, and you almost certainly did not choose most of them by name. The AI agent chose them, usually correctly, sometimes by hallucinating a name that happens to exist and belong to someone with bad intentions, and occasionally from a package whose maintainer's publishing credentials were stolen after you already had it installed. Section 2 walked through what this looks like at the scale of a real attack (Nx, Shai-Hulud, slopsquatting); this section is what to actually do about it before launch.

The first and cheapest control is a lockfile, a file (package-lock.json for npm, yarn.lock, or pnpm-lock.yaml) that pins every package in your dependency tree to an exact version rather than a range. AI coding agents generate lockfiles automatically as a side effect of installing packages, but they are frequently excluded from version control by an overly broad .gitignore file, or overwritten silently on a later install. npm's own documentation is explicit that this file "is intended to be committed into source repositories" precisely so that "teammates, deployments, and continuous integration are guaranteed to install exactly the same dependencies" - npm docs. Committing your lockfile and running installs with the "clean install" flag (npm ci rather than npm install) in any deployment pipeline ensures every environment gets the exact versions that were tested, not whatever the latest matching version happens to be on deploy day, which is precisely the mechanism a worm like Shai-Hulud relies on to spread through routine dependency updates.

Beyond pinning, you need something actively checking your dependencies for known vulnerabilities and malicious behavior, because a pinned version can still be the version that turns out to be compromised. npm audit is free and built into npm itself, and is a reasonable starting point, though your real risk surface is typically the 5 to 10% of flagged issues that are direct production dependencies with an actual exploitable path, not the full list the command prints - safeguard.sh. For continuous, more thorough scanning, Snyk offers a free tier and a Team plan starting at $25 per contributing developer per month, covering software composition analysis, static code analysis, and container scanning in one product. Socket takes a behavioral approach rather than a known-CVE-database approach, analyzing what a package actually does (network access, filesystem writes, obfuscated code, install scripts) to catch brand-new supply chain attacks before they accumulate a CVE entry, with a free tier covering 1,000 scans a month and paid tiers starting at $25 per developer per month.

For catching security bugs in the code your team or your AI agent actually wrote, rather than in third-party packages, Semgrep is the most commonly recommended static analysis (SAST) tool for teams past the earliest prototype stage: free for up to 10 contributors and 50 repositories, with paid modules (code scanning, supply chain, secrets) starting at $30 per contributor per month each. GitHub's own Code Security add-on, which bundles CodeQL-powered scanning, Copilot Autofix, and dependency review, costs $30 per active committer per month, alongside a separate Secret Protection add-on at $19 per active committer per month - GitHub. None of these tools require you to understand the vulnerabilities they find in order to benefit from them; each one produces a plain-language description of the problem and, increasingly, a suggested fix you can hand back to your AI coding agent to apply.

Set up one dependency scanner and one secret scanner before your first deploy, not after, because retrofitting security tooling onto a codebase with months of accumulated, unreviewed AI-generated dependencies is a much larger project than starting with the scanner running from day one. Wire the scanner into your deployment pipeline so a critical finding blocks the deploy automatically rather than producing a report nobody reads, and revisit the findings weekly during active development, since new packages get added constantly as you iterate with your AI agent and each one is a fresh opportunity for the exact failure modes covered in section 2.

The deeper structural point behind this entire section connects back to section 1: a human reviewer used to at least skim a new dependency's name and purpose before it entered a codebase, catching an obviously wrong or suspicious package by instinct. An AI agent installing a package to satisfy a prompt has no equivalent instinct, and neither, usually, does the non-technical founder watching the agent work. Automated scanning is not an optional nice-to-have layered on top of AI-assisted development, it is the direct structural replacement for the review step that AI-assisted development removed, and treating it as optional is treating the removed checkpoint as if it never mattered in the first place.

7. API Security: Rate Limiting, CORS, Input Validation, and IDOR

Every app built in 2026, no matter how simple it looks from the outside, is a set of API endpoints that accept requests from the internet and decide what to do with them. This section covers the four most common ways those endpoints fail when an AI agent writes them without specific security instructions, and each failure mode is worth understanding on its own terms rather than as an abstract checklist item, because each one has a distinct, testable symptom you can check for yourself.

Insecure direct object reference (IDOR) is the pattern already introduced in section 4: an endpoint like /api/invoices/47 that returns data based on an ID in the URL without confirming the requesting user actually owns invoice 47. It is consistently one of the most common vulnerabilities found in AI-generated applications because the "happy path" (a logged-in user requesting their own data) works perfectly in every demo and every test the founder personally runs, since the founder is always testing with their own account and their own data. The bug only becomes visible when a second account exists and someone deliberately tries someone else's ID, which is precisely the step nobody performs before launch because it requires imagining yourself as an attacker rather than as a user.

CORS (cross-origin resource sharing) misconfiguration is a narrower but genuinely common AI-generated mistake: browsers block a webpage on one domain from making requests to an API on a different domain by default, and CORS is the mechanism a server uses to explicitly permit specific trusted domains to bypass that block. AI coding agents frequently generate cors() with no arguments or an explicit wildcard origin (Access-Control-Allow-Origin: *) because it eliminates a source of friction and errors during local development, and that setting then ships unchanged to production - BSWEN. A wildcard origin combined with cookie-based authentication is a genuinely dangerous combination: any website on the internet can make a request to your API on behalf of a logged-in visitor and read the response, turning a convenience setting into a cross-site data exfiltration path - PortSwigger. The fix is to replace the wildcard with an explicit list of the exact domains your frontend is served from, and to only enable credentialed requests for origins on that list.

Rate limiting protects against two related problems: an attacker (or, just as often, a misbehaving script or a runaway AI agent making repeated calls) hammering an expensive endpoint hard enough to run up your infrastructure bill or your third-party API costs, and brute-force attempts against a login endpoint. Without any limit, a login route will happily accept ten thousand password guesses a minute from the same IP address, and an AI-generated app rarely adds this limit unless specifically prompted to, because the limit is invisible in every normal test. Cloudflare ships WAF and basic rate limiting rules on every plan including the free tier, with Pro plans (roughly $20 to $25/month) allowing around ten rules and Business plans (roughly $200 to $250/month) allowing around fifteen, all under a flat-rate pricing model rather than usage-based billing - WAF Pricing. At minimum, put a rate limit on every authentication endpoint and every endpoint that calls a paid third-party API (payments, LLM inference, email sending) before launch, since those two categories are where an unlimited endpoint turns directly into either a security incident or a surprise invoice.

Input validation is the broadest of the four and the one most likely to have knock-on effects elsewhere: every value your API accepts from a user (a form field, a URL parameter, a file upload) should be checked against what it is actually supposed to be before your application does anything with it, rather than trusted implicitly. A field expecting an email address should be validated as an email address; a field expecting a number should reject a string that contains SQL syntax; a file upload endpoint should check the actual file type rather than trusting the filename extension the browser reports. Weak input validation is the underlying mechanism behind SQL injection, and while AI models handle the classic version of that specific attack reasonably well (an 83% pass rate in Veracode's 2026 testing, per the chart in section 1), a December 2025 study by security firm Tenzai testing five major AI coding agents found every single one introduced server-side request forgery (SSRF) in the same type of feature, a related class of input-trust failure where the server is tricked into making a request to an internal resource on the attacker's behalf - OX Security.

Testing all four of these yourself before launch does not require specialized tools. Pull up your app's network requests in your browser's developer console, then for each API endpoint you find: try changing the ID in the URL to a number that belongs to a different account and confirm you get rejected, try calling the endpoint from a different domain in your browser console and confirm CORS blocks it, try calling the same endpoint rapidly in a loop and confirm you eventually get rate-limited, and try submitting an obviously malformed value in every form field and confirm the server rejects it rather than accepting it silently. This manual pass takes an afternoon and catches the majority of what the automated scanners from section 6 will otherwise flag anyway, and doing it yourself first builds the intuition to ask your AI agent for the right fix when the scanner does find something.

8. Infrastructure: HTTPS, WAF, DDoS Protection, and Environment Separation

The application layer covered in sections 3 through 7 sits on top of infrastructure that has its own, separate set of pre-launch checks. Most of these are handled automatically by modern hosting platforms, which is genuinely good news, but "usually automatic" is not the same as "guaranteed," and the gaps tend to be exactly the parts a non-technical founder has no reason to think to verify.

HTTPS (encrypted traffic between the browser and your server) is on by default on essentially every managed hosting platform in 2026, including Vercel, Netlify, Render, and Founden's own deployment pipeline. What is frequently missing is HSTS (HTTP Strict Transport Security), a header that tells the browser to never even attempt an unencrypted connection to your domain again after the first visit. Without it, a single link that happens to point to the http:// version of your site (easy to generate by accident, common in old bookmarks or copy-pasted URLs) can expose a session cookie in plain text before the automatic redirect to HTTPS even happens - uxcontinuum. Most hosting platforms let you enable HSTS with a single configuration flag or dashboard toggle; confirm it is on rather than assuming HTTPS alone covers you.

A web application firewall (WAF) sits in front of your app and filters out obviously malicious traffic patterns (known attack signatures, bot traffic, common exploit attempts) before they ever reach your application code. Cloudflare includes basic WAF protection, free SSL, and DDoS protection on its free plan, which is a meaningfully strong baseline for a solo founder's first launch at zero cost, with paid Pro and Business tiers adding more granular rules and higher rate-limiting rule counts as your traffic and risk profile grow - WAF Pricing. DDoS protection specifically matters more than most non-technical founders assume even for a small app, because a flood of automated traffic does not need to be a targeted attack to take your app offline; it can just as easily be a misconfigured bot, a scraper, or your own AI agent's test script left running against production by mistake. Putting your app behind Cloudflare or an equivalent CDN/WAF layer is a genuinely low-effort, high-leverage step that most managed hosting platforms make close to a checkbox to enable.

Environment separation, keeping development, staging, and production as genuinely separate environments with separate databases and separate credentials, is the infrastructure equivalent of the authorization checks covered in section 4: invisible in a working demo, and the source of some of the worst incidents when it is missing. A founder iterating quickly with an AI agent will often test directly against a "production" database because a second environment felt like unnecessary setup overhead during the early build. The risk compounds once real users and real data exist: a bug your AI agent introduces while you are asking it to add a new feature can now delete or corrupt live customer data rather than a disposable test table, and a leaked development credential (see section 3) is now a leaked production credential. Before you have your first real user, set up at minimum two environments with entirely separate database instances and separate API keys for every third-party service, and get comfortable treating "production" as a place your AI agent's mistakes are never allowed to reach directly.

Where you deploy shapes how much of this you inherit automatically versus how much you configure by hand. Our comparison of where to deploy your app in 2026 and our guide to running a Python backend on Vercel both cover the infrastructure trade-offs of specific hosting choices in more depth than fits here, and our broader look at the AI-native company tech stack covers how these infrastructure pieces fit together end to end. Founden provisions deployment, HTTPS, and the hosting layer as part of generating the app itself, which removes the specific failure mode of a founder forgetting to configure TLS or leaving a staging environment pointed at a production database, though it does not remove your responsibility to verify the application-layer checks from sections 3 through 7, which depend on what your specific app does rather than on how it is hosted.

9. If Your App Talks to an LLM: Prompt Injection and Agentic Risk

Everything covered so far applies to any app, regardless of whether it has AI features of its own. If your product itself calls an LLM, for a chatbot, a content generator, an AI agent that takes actions on a user's behalf, or a search feature with an AI summary, you inherit an additional, distinct category of risk that traditional web security checklists do not cover at all, because the vulnerability lives in natural language rather than in code syntax.

The OWASP Gen AI Security Project maintains two related frameworks that map this territory precisely, and both were published or updated for 2026. The OWASP Top 10 for LLM Applications covers risks in any system that generates content with a model: prompt injection (an attacker's instructions hidden in content the model reads, such as a webpage or an uploaded document, override your intended instructions), sensitive information disclosure (the model reveals data it should not, including its own system prompt or another user's context), supply chain risk (compromised model weights, fine-tuning data, or plugins), data and model poisoning, improper output handling (the model's raw output gets executed or rendered without sanitization, the AI-era version of cross-site scripting), excessive agency, system prompt leakage, vector and embedding weaknesses, misinformation, and unbounded consumption, where an attacker triggers unlimited, uncontrolled calls to your LLM provider and runs up your bill - OWASP GenAI Security Project.

Where your app goes further and lets the model actually take actions (send an email, call an API, modify a database, browse the web on the user's behalf) rather than just generate text, the newer OWASP Top 10 for Agentic Applications, published December 9, 2025, becomes the more relevant framework. It catalogs ten risks specific to autonomous agents, developed with more than 100 industry security experts and researchers: goal hijacking (an attacker redirects the agent's objective through content it reads, not code it runs, so it pursues the attacker's goal while believing it still serves the user), tool misuse, identity and privilege abuse (the agent operates with more permission than the task requires), agentic supply chain vulnerabilities, unexpected code execution, memory and context poisoning, insecure inter-agent communication, cascading failures across a multi-agent system, human-agent trust exploitation, and rogue agent behavior - OWASP GenAI Security Project.

The practical version of this for a founder building an AI feature into their product, rather than a security researcher studying it abstractly, comes down to a small number of concrete decisions. Never let user-supplied or externally-fetched content (a webpage the model reads, a document a user uploads, an email the agent processes) be treated with the same trust level as your own system instructions, because the model cannot reliably tell the difference between "the developer told me to do this" and "a webpage I read told me to do this" once both are in the same context window. Scope every tool or API call your AI agent can make to the absolute minimum permission it needs for its actual job (a customer support bot that can look up an order should not also be able to issue a refund unless that is explicitly the feature), and never give an AI agent standing access to a production database write operation without a human confirmation step in between for anything destructive or financially consequential.

If your AI feature is built with Claude Code or a similar coding agent during development, and it separately ships an MCP server as part of your product for other AI tools to connect to, treat that MCP configuration with the exact same secret-scanning rigor covered in section 3, since it is currently one of the fastest-growing categories of credential leak according to GitGuardian's 2026 data cited earlier in this guide. Founden is built on Anthropic's current Claude model lineup, including Claude Opus 5 and Claude Sonnet 5, both confirmed as Anthropic's current generation as of this writing, and exposes its own MCP server so the platform can be driven from Claude, Cursor, or ChatGPT directly. The same discipline applies regardless of which underlying model or platform you build with: an AI feature is a new, distinct attack surface layered on top of everything else in this guide, not a replacement for it.

10. Monitoring and Incident Response

Every control covered so far reduces the probability something goes wrong. None of them reduce it to zero, and the gap between "we prevented every possible issue" and "we will find out about a real issue within minutes instead of months" is where monitoring and incident response live. A founder who has done everything in sections 3 through 9 correctly but has no visibility into what their app is actually doing in production is still flying blind the moment something unexpected happens, whether that is an attack, a bug, or simply a dependency update that silently broke something.

Error monitoring is the most immediately useful and lowest-effort piece of this to set up, because it requires almost no ongoing maintenance once configured and it surfaces problems you would otherwise only discover from an angry customer email. Sentry, the most widely used tool in this category, offers a free Developer tier covering 5,000 error events a month for a single user, a Team tier at $26/month (billed annually) covering 50,000 events, and a Business tier at $80/month with additional features like unlimited custom dashboards, which is enough headroom for most apps through their first year of real traffic. Installing it typically takes adding one package and one initialization snippet, something any AI coding agent can do correctly on a direct prompt, and the payoff is an immediate, searchable record of every error your app throws in production, including the exact request, user, and stack trace that caused it.

Beyond error tracking specifically, your logs themselves need a second, security-focused pass before launch, because AI-generated middleware has a specific and well-documented bad habit: logging the entire request body for debugging convenience, including fields like passwords, tokens, and payment card numbers that were only ever meant to pass through your server, never be written to disk - technetexperts. Search your existing logging configuration and your actual log output for the literal strings password, token, authorization, and card, and confirm none of them are being written in plain text anywhere your logging provider stores them, since a log aggregation service is a much softer target than your primary database and is frequently overlooked in a security review that focuses only on the app itself.

For anything handling money, health information, or data you would be legally or reputationally obligated to disclose a breach of, a basic incident response plan is worth writing down before you need it, not after. This does not need to be a formal document; it needs to answer three questions in advance, when you have time to think clearly, rather than in the middle of an actual incident when you do not: who gets notified the moment something looks wrong (even if that is just you and a co-founder), how do you rotate every credential the app uses if you suspect any one of them is compromised, and what do you tell affected users if their data was exposed, given that most jurisdictions with data protection laws (covered in the next section) have specific, legally mandated timelines for that disclosure. Writing these three answers down takes twenty minutes and removes the worst possible failure mode during a real incident, which is losing the first critical hours to confusion about who is supposed to do what.

The deeper reason this section belongs in a pre-launch checklist rather than a "someday" list is the same structural argument from section 1: the human reviewer who used to catch mistakes before they shipped is gone, but a human still needs to catch what got through after the fact, and that human cannot do their job without visibility into what actually happened. Monitoring is not a nice-to-have layered on top of a secure app, it is the mechanism that turns "we think we are secure" into "we know what is actually happening," and it is one of the few controls in this entire guide that pays for itself the very first time it catches something, whether that something is a genuine attack or simply a bug your AI agent introduced while adding an unrelated feature.

11. Compliance Basics: GDPR, CCPA, and SOC 2

Compliance is often treated as a problem for later, something you deal with once you have real revenue and a legal budget. For two of the three frameworks covered in this section, that assumption is wrong from your very first user, and getting it wrong is a legal and financial exposure entirely separate from the technical vulnerabilities covered in the rest of this guide.

GDPR (the EU's General Data Protection Regulation) applies to any business that processes the personal data of people in the European Union, with no revenue threshold, no company size exception, and no requirement that your business itself be based in Europe. If your app has even one user who signs up from an EU country, GDPR applies to you the moment that happens, full stop - Usercentrics. The practical implications for a newly launched app are narrower than the full regulation might suggest: you need a clear, accessible privacy policy that explains what data you collect and why, a lawful basis for collecting it (consent is the most common for a consumer app), a way for users to request their data be deleted, and you need to avoid the specific technical mistakes covered earlier in this guide, since an exposed database (section 5) or a leaked secret that grants access to user data (section 3) is a GDPR violation on top of being a security incident. Our dedicated guide to making your AI app EU-compliant by December 2026 covers this specific deadline and the fuller compliance picture in depth.

CCPA (the California Consumer Privacy Act), by contrast, has genuine size thresholds: it applies to for-profit businesses with over $26,625,000 in annual gross revenue, or businesses that derive more than half their revenue from selling personal data, or businesses processing the personal information of over 100,000 California residents a year, meeting any single one of which triggers full compliance obligations - Sprinto. Most apps at launch will not meet any of these thresholds yet, which means CCPA is genuinely a "prepare for later" item for a brand-new product in a way GDPR is not, though the threshold is worth revisiting the moment you have meaningful California traffic, since new 2026 regulations added formal risk assessment requirements and mandatory cybersecurity audits on top of the base law.

SOC 2 is different in kind from the two data protection laws above: it is a voluntary, paid audit that verifies your security controls to potential enterprise customers, not a legal requirement. It becomes relevant the moment you try to sell to a business customer with its own procurement and security review process, which for many B2B products happens earlier than founders expect, often as soon as the first mid-sized company evaluates the product seriously. Most startups spend between $25,000 and $50,000 for a first-year SOC 2 Type 2 certification covering the audit itself, required tooling, and a compliance automation platform, though a smaller company (under 50 employees) pursuing a first Type 1 report can spend under $15,000 for the audit and platform combined - Sprinto. This is not a pre-launch item for the overwhelming majority of apps covered by this guide; it is worth knowing the number exists and roughly what it costs so that when an enterprise prospect asks "are you SOC 2 compliant" six months after launch, you already know what you are signing up for rather than discovering the cost mid-negotiation.

The throughline across all three frameworks is that the technical security work in sections 3 through 8 of this guide is not separate from compliance, it is the substance of it. A GDPR data subject access request is trivial to fulfill if your database has clean row-level security scoped to individual users (section 5); it is a genuine engineering project if your data model never separated one user's data from another's in the first place. A SOC 2 auditor's questions about access control, secret management, and monitoring map almost one-to-one onto sections 3, 4, and 10 of this guide. Doing the security work correctly from launch is, in practice, most of the compliance work done in advance, which is the more useful way to think about this section than as a separate checklist competing for your attention against the rest of the guide.

12. The Pre-Launch Pentest and Bug Bounty Question

Everything in this guide so far is something you or an automated tool can check yourself. This final layer, having an outside party deliberately try to break your app before real users can, is different in kind: it exists specifically to catch what you did not think to check, because you are, by definition, too close to your own app to see it the way an attacker would.

For most apps launching for the first time, especially those without payment processing or sensitive health or financial data, a formal, paid penetration test or bug bounty program is not the right first move, and treating it as mandatory would misallocate a limited budget away from the more foundational work in sections 3 through 8. The honest ordering is: fix the concrete, well-understood gaps first (secrets, access control, RLS, dependencies), because a professional pentest report that comes back listing "no row-level security on your users table" is an expensive way to learn something section 5 of this guide already told you for free.

Once your app handles payments, health data, or any information a breach would make genuinely newsworthy, an external review becomes worth budgeting for. HackerOne and Bugcrowd, the two largest bug bounty platforms, structure their pricing around platform access fees plus researcher payouts: a basic vulnerability disclosure program (essentially "here is how to report a bug to us responsibly," with no guaranteed payout) runs roughly $8,000 to $12,000 a year on HackerOne, while a private, invite-only bug bounty program with real payouts to researchers runs $25,000 to $40,000 a year in platform fees before payouts, and Bugcrowd's pricing sits in a comparable $30,000 to $150,000-plus range depending on program type and scope - CipherSSecurity. Both companies commonly negotiate 15 to 25% off those initial quotes for multi-year commitments, and a scoped, one-time penetration test from an independent security firm (rather than an ongoing bug bounty program) is frequently a cheaper and faster way to get a pre-launch review for a first product, though it will not catch anything discovered after the engagement ends the way an ongoing program does.

A middle-ground option that costs nothing but time is asking a developer friend, a technical advisor, or another founder in your network who has shipped a production app before to spend an hour deliberately trying to break yours: attempting the IDOR and CORS tests from section 7 themselves, trying to reach your admin panel without logging in the way the Baudr attacker did in section 2, and generally approaching your app the way an impatient, mildly hostile stranger would rather than the way you, its builder, naturally do. This costs a coffee and an hour of someone's time, and it catches a meaningful share of what a $30,000 program would otherwise find, precisely because most real-world breaches of AI-built apps in 2026 have not required sophisticated techniques, only someone willing to try the obvious thing first.

Whichever path fits your stage and budget, the goal of this final layer is the same: someone other than you, thinking like an attacker rather than a builder, spends time trying to break the specific thing you shipped. Every other section of this guide is a defense against a known, general category of mistake. This section is the check for the mistake nobody wrote a checklist item for yet, which is exactly the kind of gap that both the Baudr incident and the Base44 disclosure from section 2 turned out to be in hindsight.

13. Where the Platform Should Carry the Load vs Where You Still Own It

Reading sections 3 through 12 in sequence can feel like a lot for one person to be responsible for, and the honest answer is that it is, if you are building entirely by hand with a general-purpose coding tool and no managed platform underneath you. This section is about the actual division of labor between what a platform reasonably absorbs on your behalf and what stays yours no matter how good the platform is, because conflating the two in either direction, assuming a platform handles everything, or assuming nothing does, produces the exact incidents documented in section 2.

Founden builds and operates a complete company from one conversation: the website, a customer-facing app with authentication and billing already wired in, an admin dashboard for the operational side of the business, the underlying database, and deployment, rather than handing a founder a codebase and leaving each of those pieces for them to individually assemble and secure. That structural difference matters directly for this guide: several of the specific failure modes in sections 3 through 8 exist precisely because a founder is manually stitching together an authentication provider, a database, a hosting platform, and a payment processor, each with its own defaults, and the gaps appear in the seams between them. A platform that generates the app, the database, and the deployment pipeline as one coherent system removes an entire category of seam-level mistake, environment separation done inconsistently, a database connection string configured differently in each environment, an auth provider wired up correctly on the frontend but not enforced on the backend, by construction rather than by the founder remembering to get every piece right independently.

That said, no platform, including this one, removes your responsibility for the decisions that are specific to your product rather than generic to how apps are built. Section 5's per-table RLS review is about your data model, which tables hold sensitive information and which do not, a decision only you can make because only you know what your app actually stores. Section 9's LLM-specific risks depend entirely on what your AI feature is prompted to do and what tools it has access to, decisions that live in your product design, not in the underlying infrastructure. Section 11's compliance questions depend on where your users are located and what data you choose to collect from them. And section 12's external review exists precisely to catch the mistake that is unique to your specific app, which by definition no platform's general-purpose defaults could have anticipated for you.

The honest way to frame this, and the way we would want any tool covered in this guide's assessment table to be judged, including our own, is: a managed platform should be evaluated on how much of the generic, repeated-across-every-app security work it absorbs (the seams between auth, database, and deployment), while the founder remains permanently responsible for the specific-to-this-product decisions no platform can make on their behalf (what data this particular app collects, who should see it, what an AI feature in this particular app is allowed to do). Treating either half as fully solved by the other is how the incidents in section 2 happened. Founden's bet, and the reason a company-operating platform is structured differently from a raw code generator like Cursor or Claude Code (both genuinely excellent tools for a developer who will own every seam personally, as covered in our Claude Code vs Codex vs Devin comparison), is that most non-technical founders are better served by not having to personally own the seams at all, while this guide exists because even that does not remove the product-specific half of the job.

If you are earlier in the process and still deciding whether a fully managed builder or a more hands-on coding tool is the right fit for what you are building, our guide to when to graduate from a vibe-coding tool and our broader market map of AI website builders cover that decision in more depth than fits here. Whichever you choose, the checklist in the next and final section applies regardless of the tool, because the product-specific half of the job never goes away.

14. The 2026 Pre-Launch Security Checklist, Assembled

Everything in this guide converges on a single pass you should walk through, in order, in the days before you flip your app from private to public. This is not a substitute for reading the reasoning in the sections above, since the why behind each item is what lets you adapt it to whatever your specific app actually does, but it is the assembled version to work through mechanically once you understand the reasoning.

Start with the secrets and dependency layer, since it is the fastest to check and the most likely to catch something embarrassing: run a secret scanner (Gitleaks or TruffleHog, both free) across your entire repository including old commits, run a dependency scanner (npm audit at minimum, Snyk or Socket for anything more thorough), confirm your lockfile is committed and your deploy pipeline uses a clean install, and rotate every credential your AI agent has touched during development as the very last step before going live. Move next to access control: walk every route and API endpoint asking whether it requires login, whether it checks resource ownership (the IDOR test from section 7), and whether role-based restrictions are enforced on the backend rather than only hidden in the frontend UI. Then move to your database specifically, confirming row-level security or an equivalent mechanism is explicitly enabled on every table holding user data, not just the obvious ones, and that your application connects with a least-privilege service role rather than a superuser credential.

From there, work through the remaining infrastructure and monitoring layer: confirm HTTPS and HSTS are both active, put your app behind a WAF and basic rate limiting (Cloudflare's free tier covers this for a first launch), verify your development, staging, and production environments use genuinely separate databases and credentials, and install error monitoring (Sentry's free tier is enough to start) before, not after, your first real user arrives. If your app has any AI feature of its own, apply the OWASP LLM and Agentic Top 10 questions from section 9 specifically to what that feature is allowed to do and what content it trusts. Close with the compliance and external-review layer appropriate to your stage: a real privacy policy and a data deletion path if you have any EU users at all, and either a friend's adversarial hour or a paid pentest if you are handling payments or health data, calibrated to what section 12 actually recommends for your specific risk level rather than defaulting to either extreme.

This ordering is deliberate and matters more than it might first appear: fixing the cheap, high-leverage items first (secrets, access control, RLS) before spending money on an external review means the external review finds the genuinely hard, product-specific problems rather than restating what a five-minute scan would have told you for free. It is also the order that best reflects where real 2026 incidents actually originated, an exposed database and an open admin panel accounted for more real damage this year than any sophisticated novel attack technique, which means the checklist above, done thoroughly, closes the door that actually got walked through in nearly every incident this guide has cited.

None of this requires you to become a security engineer, and that is the entire point of writing it this way. It requires you to spend one focused day, before launch, deliberately trying to break your own app the way an attacker would rather than testing it the way a builder naturally does, checking the specific, concrete things this guide named rather than trusting that "it works" means "it's safe." The tools that built your app in an afternoon can also fix most of what this checklist finds in about the same amount of time, once you know precisely what to ask for. A platform like Founden closes a meaningful share of the generic infrastructure gaps in this guide by construction, and the same discipline applies whether you build with a fully managed platform or a general-purpose coding agent: the checklist is the difference between shipping the app you meant to build and shipping the version of it that ends up as next year's version of section 2.

This guide reflects the AI app security landscape as of September 2026. Platform features, pricing, and default security behaviors change frequently, especially on fast-moving AI builders, so verify current defaults on whichever platform you use before you launch.