AI-Generated Code Security: Pre-Launch Checklist

In short: AI coding tools such as Cursor, Claude Code, Copilot, Lovable, Bolt and v0 can take you from idea to working app in days. But working is not the same as safe. Before launch, AI-generated code security needs its own check: secrets kept out of the code, every user limited to their own data, proper login, safe handling of input, real packages only, locked-down databases, rate limits, backups and a privacy plan.

We use AI coding tools ourselves, and they are genuinely useful. The point of this article is not "AI code is bad". It is that AI writes code that looks finished, and the security gaps are usually in the parts you cannot see on screen.

Why AI-generated code security needs a separate check

AI tools are trained to produce code that runs and matches your request. Security is often something you did not ask for, so it is easy for the tool to leave it out.

The research backs this up. Veracode tested code from more than 100 large language models across Java, Python, C# and JavaScript, and found that 45% of the code samples failed its security tests and introduced OWASP Top 10 weaknesses (Veracode, 2025 GenAI Code Security Report). In the same study, the models failed to defend against cross-site scripting in 86% of the relevant samples, and Java had the highest failure rate at 72%.

There is a real-world example too. In 2025 a researcher scanned 1,645 apps from Lovable's public showcase and found 303 exposed endpoints across 170 projects, about 10% of those checked. Some exposed user emails, phone numbers, payment details and API keys. The cause was not a clever hack: the database access rules (Supabase "Row Level Security") were missing or wrong (Matt Palmer, statement on CVE-2025-48757). Lovable disputed the CVE, saying each customer is responsible for their own app's data. Either way, the person launching the app owns the risk.

The common risks, in plain English

1. Exposed API keys and secrets

Secrets are passwords for machines: your Stripe key, OpenAI key, database password, email service key. AI tools sometimes paste them straight into the code, or into front-end files that every visitor's browser downloads. GitGuardian counted 23.8 million secrets leaked on public GitHub repositories in 2024, a 25% rise on the year before (GitGuardian, State of Secrets Sprawl 2025).

Technical note: secret keys belong in server-side environment variables, never in browser code or a Git repository. Keys marked "public" or "anon" (such as Supabase's anon key) are designed to be visible, but only if access rules are switched on behind them.

2. Missing access checks between users

This is the big one. Your app shows a customer their own invoices at a link like /invoices/1042. What happens if they change it to /invoices/1043? If the code does not check who owns that invoice, they see someone else's. Broken access control is number one in the OWASP Top 10:2025, the industry's standard list of web application risks. AI tools often build the screen correctly and forget the check on the server.

3. Weak authentication

Watch for passwords stored without proper hashing, password reset links that never expire, sessions that stay valid forever, admin pages protected only by being "hidden", and no two-factor option for admins. Where you can, use a proven login service (Supabase Auth, Clerk, Auth0, Firebase Auth and similar) rather than a login system the AI wrote from scratch.

4. SQL injection and cross-site scripting (XSS)

Both happen when the app trusts what users type. With SQL injection, text typed into a form is treated as a database command. With XSS, text such as a review or a profile name is shown back on the page as live code, which can steal other users' sessions.

Technical note: use parameterised queries or an ORM, never build SQL by joining strings, and escape anything users submit before it is displayed.

5. Outdated or invented packages

Modern apps are built from hundreds of open-source packages. AI tools sometimes suggest old versions with known holes, and sometimes suggest packages that do not exist at all. A USENIX Security 2025 study generated 576,000 code samples from 16 models and found 205,474 unique made-up package names; on average, at least 5.2% of packages suggested by commercial models and 21.7% by open-source models were hallucinated (Spracklen et al., USENIX Security 2025).

Why it matters: an attacker can register one of those invented names and fill it with malware, so the next person who installs it gets infected. This is called "slopsquatting". Old, unpatched software is a risk on any site, AI-built or not, as we covered in our post on critical PHP vulnerabilities.

6. Open databases and storage buckets

Firebase, Supabase, S3 and similar services make it easy to store data and files. They also make it easy to leave them readable, or writable, by anyone on the internet. In the Lovable research above, testers could even write a record marking a payment as "paid" without going through Stripe (Matt Palmer). Check that every table and bucket has rules, and that the rules have actually been tested from a logged-out browser.

7. No rate limiting

Without limits, a bot can try thousands of passwords, spam your contact form, or run up a large bill on your paid AI or SMS service. If your app includes an AI feature, the OWASP Top 10 for LLM Applications lists "Unbounded Consumption" alongside prompt injection and sensitive information disclosure as key risks.

8. Missing backups

In July 2025, SaaStr founder Jason Lemkin reported that Replit's AI agent deleted his project's database during a code freeze. Replit's CEO called it "unacceptable" and announced automatic separation of development and production databases (The Stack). The lesson for everyone: keep test and live data apart, do not give an AI agent unrestricted access to your live database, and keep backups that you have actually restored at least once.

9. Privacy and data protection

If you collect names, emails, phone numbers or payments, data protection law applies to you whoever wrote the code. In India, the Digital Personal Data Protection Rules were notified in November 2025, putting the DPDP Act, 2023 into operation in phases (PIB backgrounder). Customers in the UK or EU bring GDPR into play. At a minimum: collect only what you need, publish an honest privacy policy, know where the data is stored, and have a plan for telling people if something goes wrong.

Risk and what to check

Risk	What to check
Exposed secrets	Search the code and Git history for keys; confirm secret keys live only on the server; rotate any key that was ever committed.
Missing access checks	Log in as user A, copy a link to A's data, open it as user B. You should get an error.
Weak login	Use a proven auth provider; reset links expire; admin accounts use two-factor.
Injection and XSS	Type `<script>` and a stray apostrophe into every form; nothing should break or run.
Bad or invented packages	Check every package exists, is maintained and is widely used; run `npm audit` or the equivalent.
Open database or storage	Access rules switched on for every table and bucket, tested from a logged-out browser.
No rate limiting	Limits on login, sign-up, forms and any paid API; spending caps set with providers.
No backups	Automatic daily backups, stored separately, with one test restore done.
Privacy	Privacy policy, minimum data collected, cookie consent where needed, breach plan.

Your pre-launch AI code security checklist

Work through this before you share the link with real customers.

Ask the AI to review its own work, then do not stop there. Prompt it to look for the risks in this article. Treat its answer as a first pass, not a sign-off.
Move every secret to environment variables and rotate any key that has ever appeared in code, chat logs or a public repository.
Test access with two accounts. Try to view, edit and delete the other account's data using links and IDs.
Turn on database and storage rules (for example Supabase RLS or Firebase Security Rules) and test them while logged out.
Use a proven login provider and switch on two-factor for every admin.
Check your packages. Remove anything unused, confirm the rest are real and maintained, and run a dependency audit.
Test your forms with odd input: very long text, symbols, HTML tags.
Add rate limits and spending caps on login, sign-up, forms, AI features and SMS or email sending.
Separate test and live environments, and do not give AI agents write access to live data.
Set up backups and restore one to prove they work.
Switch on HTTPS everywhere, hide detailed error messages from visitors, and remove test pages and demo accounts.
Publish a privacy policy that matches what the app really collects.
Set up monitoring and alerts so you hear about errors and unusual activity before your customers do.
Plan for after launch. Packages and platforms keep releasing security fixes; someone needs to apply them. Ongoing website maintenance covers this.

When to get a professional security review

The checklist is enough for a simple brochure site or a prototype with no real users. Get a professional review before launch if any of these apply:

You store personal data, health information or anything sensitive.
You take payments or manage subscriptions.
Users log in and have their own private data (most web apps and SaaS products).
Nobody on the team can read and explain the code the AI wrote.

A good review checks the things automated scanners miss, especially access rules between users,. Our website security service covers this,. If your team already uses a ticket system, small fixes can be handled through ticket-based support rather than a large project.

Use AI to build, and people to check

AI coding tools have made building software faster and cheaper, and that is a good thing. The risks above are not new; they are the same mistakes human developers have made for years. The difference is speed: an app can now reach real users before anyone has looked at how it handles their data.

So build with AI, then slow down for one afternoon before launch and work through the checklist. If you would like a second pair of eyes on an AI-built site or app, Rachyet can review it and fix what needs fixing. Get in touch and tell us what you have built.

Sources

Frequently asked questions

Is code written by AI tools less secure than code written by people?

Not always, but it needs checking. Veracode's 2025 study found 45% of AI-generated code samples failed security tests. AI tools focus on making code work as requested, and security steps you did not ask for are easy to miss. Reviewing access rules, secrets, input handling and packages before launch closes most of the common gaps.

Can I just ask the AI tool to make my app secure?

It helps, and you should do it, but it is not enough on its own. AI tools can miss problems in their own code, especially access checks between users and database rules. Treat the AI's security review as a first pass, then test the important things yourself, such as trying to open another user's data with a second account.

What is slopsquatting?

Slopsquatting is when attackers register software package names that AI tools invent. A USENIX Security 2025 study found models suggested over 205,000 unique non-existent package names. If someone publishes malware under one of those names, anyone who installs the AI's suggestion gets infected. Always confirm a package exists, is maintained and is widely used before installing it.

Do I need a professional security review for a small website?

For a simple brochure site with no logins or stored customer data, the checklist in this article is usually enough. A professional review is worth it when users log in, you store personal or sensitive data, you take payments, or nobody on your team can explain how the AI-written code works. Investors and enterprise clients may also expect one.

Which security risk is most common in AI-built apps?

Missing access checks are among the most serious. Broken access control is number one in the OWASP Top 10:2025, and the 2025 research into Lovable-built apps found exposed data in about 10% of projects scanned, caused by missing or wrong database access rules. Test it simply: log in as one user and try to open another user's data.

AI-Generated Code Security: A Checklist Before You Go Live

Why AI-generated code security needs a separate check