Is AI-written code secure? 7 things to check before launch

Not by default. In a 2025 test by Veracode, AI chose the insecure solution in 45% of tasks when it had a secure and an insecure option. The code worked. It was not secure.

That does not mean every app with AI-written code is unsafe. It means you cannot assume security; you have to check it. This article lists seven checks to run before launch and explains which ones you can do yourself.

What the research shows

Veracode tested more than 100 language models on 80 coding tasks. Each task had a secure and an insecure solution. In 45% of cases the model picked the insecure one. For Java the failure rate was above 70%, and for protection against cross-site scripting (XSS) the models failed to write secure code in 86% of cases.

Two things matter here. First, this is a controlled test, not the share of all AI-written code in use today. Second, Veracode found that newer models write better working code but are no better at security than older ones.

A second study matters even more for clients. Researchers at Stanford compared programmers with and without an AI assistant. The group with the assistant wrote less secure code in four of five tasks. It was also more confident that its code was secure. The study used a model from 2022, so the numbers do not carry over directly to today's tools. The pattern does: AI lowers not only security but also doubt.

What happens in practice: 170 open databases

In May 2025 the vulnerability CVE-2025-48757 was published for apps built with Lovable. Researcher Matt Palmer scanned 1,645 such apps. In 170 of them, one in ten, the database was open to anyone on the internet, without logging in. The exposed data included users' personal data and keys to other services. Semafor reported on the case.

The cause was not a sophisticated attack. The rules that decide who may read which record in the database were missing. The apps worked, login worked, and every user saw only their own data on screen. The database underneath answered anyone who asked it directly.

Whose fault it was, the tool's or the app authors', is still debated. For the user whose data was exposed, it makes no difference.

7 things to check before launch

1. Keys and passwords in the code

AI often writes the key for the database, the payment system or the AI model straight into the code, because that is the shortest path to a working example. If that code runs in the browser or sits in a public repository, everyone has the key.

How to check: search the code for "key", "secret", "token" and "password". Open the page source in the browser and search for the same. Replace any key you find; do not just hide it.

2. Who may access which data

This is the mistake from the example above. Separation of data has to be enforced in the database or on the server, not on the screen.

How to check: create two accounts. With the second, try to open a record that belongs to the first by changing the number or identifier in the address. If it opens, you have a problem.

3. Input validation

Every piece of data that comes from a user has to be checked on the server: length, type and content. AI often writes that check only in the form, where it can be bypassed.

How to check: enter very long text, characters such as < > ' " and an empty value into the fields. The app should reject the input with a clear message, not with an error or a blank screen.

4. Login, passwords and sessions

Check that passwords are stored protected, that login attempts are limited, that password reset works only for the account owner, and that a session really ends after logout.

How to check: enter a wrong password ten times in a row. If the app does not stop you, it will not stop automated guessing either.

5. Libraries and dependencies

An app is assembled from dozens of third-party libraries. AI sometimes suggests outdated versions with known vulnerabilities, and sometimes a library that does not exist. Someone can register that name and put malicious code in it.

How to check: run the dependency audit built into most development environments. For every library you do not recognise, check who maintains it and how many people use it.

6. What you send to the AI model provider

If the app uses an AI model, it sends data to it. Check whether that includes your customers' personal data, where it is processed, and whether you have a data processing agreement with the provider. Under GDPR that is your responsibility.

How to check: find the places in the code that call the AI model and look at exactly what is in the request.

7. Backups and logs

When something goes wrong you need two things: a copy of the data and a record of what happened. Prototypes have neither.

How to check: restore a backup into a test environment. Then try to find out who logged in yesterday and what they changed. If you cannot, you will not be able to after a breach either.

What you can check yourself and when that is not enough

You can run the two-account test, search the code for keys, try the inputs and run the dependency audit yourself. It takes an afternoon and catches the most obvious mistakes.

Asking AI to review the security of its own code also helps. It will find some of the problems. Do not rely on it: the same model has the same blind spots when reviewing as when writing.

Checking it yourself is not enough when the app stores personal, financial or health data, when it takes payments, or when you sell it to companies that will ask for evidence of a security review.

In those cases an independent review makes sense. It is part of our AI project rescue review: in two weeks you get a prioritised list of risks, meaning what must be fixed before launch, what can wait, and what is not worth fixing. See the AI Project Rescue package for what it covers and what it costs.

Frequently asked questions

Is AI-written code less secure than code written by a person?

Not necessarily. People write insecure code too. The difference is review: in a well-run team, someone else reads the code before it ships. In an app built with an AI tool that step is often missing, because nobody reads the code at all.

Can AI check the security of its own code?

Partly. It finds known patterns if you ask it explicitly. It does not know which data in your app is sensitive or who is allowed to see it. A person has to decide that.

Are newer AI models more secure?

According to Veracode's data, no. Newer models write code that works more often, but the share of security flaws has not gone down.

Who is responsible if data leaks?

Under GDPR the controller is responsible for protecting personal data, which means the company that offers the app. The fact that AI or an outside contractor wrote the code does not transfer that responsibility.