Security of apps written with AI: the most common flaws and how to find them

Short answer: Apps written with AI fail on security in the same places as apps written by people, except that when code is written fast, nobody sees the flaws. The most common ones are missing access control, keys in the code, unchecked input, outdated dependencies and missing logging. All of them are described in the public OWASP Top 10 list, and all of them can be found by combining an automated scan, code review and a penetration test chosen according to the app's risks.

Why it matters

AI writes working code fast, but it picks the secure variant only in part of the cases, even though this is improving. In October 2026, Veracode tested 18 language models on tasks in four programming languages and four types of vulnerabilities. The models wrote secure code in 62% of cases on average, up from 56% in the previous measurement. The best ones, Claude Opus 5.5 and GPT-6-Sol, reached 73%, so even they failed roughly one task in four. For injecting foreign code into a page (cross-site scripting), only 18% of solutions passed, and for forging log entries (log injection) 13%. For comparison, Veracode's first study in 2025 (over 100 models, 80 tasks) found a vulnerability in 45% of cases.

For the person responsible for the app, one thing follows. It does not matter whether the code was written by Claude Code, Cursor, Lovable or a colleague. What matters is whether someone reviewed it before launch the same way they would review code from a new supplier. This article is the pillar of our cluster on security and legislation: it gives an overview of where flaws come from, what they look like in business terms and how to find them. We will follow up with separate articles on prompt injection in AI agents, on a penetration test of an app built with AI, and on obligations under NIS2 and the Czech Cybersecurity Act.

Want to know where your AI-written app has weak spots? Book 30 minutes online with us. We will tell you what we would check first. Book an online call

Why AI code fails on security

A model writes code that works, not code that withstands attack. A language model learned from public code, and in it the secure variant is often the minority. When you ask for “build a login”, you get a login. If you do not add “and make sure users see only their own records”, the model in many cases will not do it, because the request did not include it. The improvement is so far uneven. In 2025, Veracode found no noticeable shift in security among newer and larger models. In October 2026, it reported a noticeable improvement for the first time: large models average 55%, small ones 51%. But it is driven mainly by XSS, log injection did not change at all, and in Java only 31% of solutions are secure.

The second reason is speed. Vibe coding, meaning programming by describing in natural language without reading the resulting code, lets you build an app over a weekend. The security check that would once happen naturally during writing and code review drops out at this pace. The result is an app that no person has read in full.

The third reason is new: apps that use AI themselves. A chatbot over company documents or an agent that handles orders has another input that can be abused. An instruction hidden in a document or an e-mail can change the model's behavior. This is called prompt injection and we will cover it in a separate article. Here it is enough to know that classic web application vulnerabilities and AI vulnerabilities add up in a single app.

OWASP Top 10 in a director's language

The OWASP Top 10 is a public list of the ten most common categories of web application vulnerabilities, published by the non-profit OWASP. The current one is the 2025 edition, the eighth. It is neither a standard nor a certification, but a common language understood by developers, testers and auditors. When a supplier tells you an app “passed the OWASP Top 10”, they mean it was checked against these ten categories. Below is a translation into questions you can ask yourself.

For decision making, what matters is that the list did not change much between the 2021 and 2025 editions. Broken access control stays in first place and the supply chain moved up. These are exactly the areas where AI-built apps fail most often, because the model does not build these boundaries on its own.

The seven most common flaws in apps written with AI

The following list is based on the OWASP Top 10 and on what tends to be most common in AI-built apps. It is not a statistic, but a practical order of what to check first. If you go through it with the people taking your app over into App as a Service, or with your own team, you will avoid most surprises.

• Missing access control. The app verifies that you are logged in, but not whether you may open this particular record. Even a non-technical person can run a practical test: two accounts, one record, an attempt to open it from the second account by changing the number in the address.
• Keys and passwords in the code. A model often puts API keys for payments, maps or AI services directly into the code or into the part of the app that runs in the browser. Anyone can read them from there, and the bill for their abuse comes to you.
• Unchecked input and injection. A form, a search or a file upload are the places where foreign content enters the app. If it gets straight into the database or a page, an attacker reads or deletes data through it. In apps with AI, prompt injection is added to this, meaning an instruction hidden in content the model reads.
• Outdated and unknown dependencies. The model reaches for a library that was popular when it was trained. Nobody checks whether it has known vulnerabilities or whether anyone still maintains it. The supply chain is third in the OWASP Top 10:2025.
• Missing logging and alerts. The app works, but nobody knows what happens in it. When someone tries a thousand passwords a minute or downloads the whole database, nobody finds out. Without logs, an incident can be neither investigated nor reported where the law requires it.
• Weak authentication. A login with no attempt limit, a password reset through a guessable link, tokens without expiry. The model generates a login that works, not a login that withstands attack.
• Default configuration in production. Test accounts, debug mode, an open admin panel, a database reachable from the internet. A prototype does not need to deal with this, production does.

An automated scan will find some of these flaws. Flaws tied to permissions and business logic, such as missing access control, are usually uncovered only by a person or a test on the running app. That is good news: you reduce most of the risk with routine, not heroics.

How to find flaws: scan, code review and penetration test

The three layers of checking do not replace each other, they complement each other. Each finds a different type of flaw and each costs a different effort. A table helps decide how much checking an app needs.

An automated scan is the cheapest and should run on every change. Besides classic scanners, AI code review also makes sense today: it goes through the whole code and finds possible flaws. Tools for development with AI often offer their own security scans, and their makers themselves state that responsibility for security stays with the author of the app. A scan is a good start, not the end.

Human review is the layer that AI-built apps lack most often. It does not have to be a full audit. There is so much AI code that a person cannot efficiently read all of it by hand, so automation goes through it first and the person focuses on the substantial risks and the stability of the foundation. An experienced developer can tell in a few hours whether the app has access control, where the keys are and whether the code stands on a stable foundation or on a series of patches. Veracode sums up its measurements the same way: not even the best model replaces independent verification.

A penetration test is an attempt to deliberately break the app from the position of an attacker. It makes sense when there is something to lose: paying customers, personal data, payments. Whether you need one and how broad it should be depends on the type of app, its architecture, the sensitivity of the data and the impact of a possible incident. For a typical web app it usually focuses on the backend, the API, login and access rights. How to commission it, what to expect and how to choose a supplier we will cover in a separate article on penetration testing of an app built with AI. An example from our practice: the Android app Photo Creation Guide for documenting crash tests in automotive has encrypted offline storage and passed a security review and a penetration test with no findings. That was possible because security was handled from the start, not after completion.

What to do with findings: order, ownership and routine

A finding without a fix is just more expensive ignorance. The output of every check is a list that needs to be ordered by business impact and assigned an owner and a deadline. First you fix what allows access to someone else's data or account takeover. Then keys and dependencies. Finally configuration and logging, which are not holes themselves, but without them you will not see the hole.

A one-off check ages as fast as code. An app you check today will have new features, new libraries and new flaws in half a year. That is why we recommend treating security as a routine: a scan on every change, human review on every major change, a penetration test according to the app's risks and after a major intervention. In companies where several people develop with AI at once, this also means central management of access and keys and deployment only to approved environments. That is exactly what we handle in AI Infrastructure. A bigger risk than the code itself is often the architecture and permissions, for example an AI agent with direct access to production.

Part of the obligations are ceasing to be voluntary. If your company falls under the new Cybersecurity Act, risk management, logging and incident reporting are requirements, not recommendations. And if the app processes personal data, security also has an impact on GDPR and AI. Verify the specific impact on your company with a lawyer.

When your own check is enough and when to bring in a team

Your own check and an automated scan are enough when:

• only your team or a few known customers use the app and it stores no sensitive data,
• the app handles no payments and does not work with health or financial data,
• someone on your team can read the code and go through the seven flaws from this article with you,
• the app uses no AI over company documents and takes no actions on behalf of users,
• an outage or a leak would not seriously harm anyone.

Bring in a team and consider a penetration test according to risk when:

• the app is going to paying customers or the public,
• it stores personal data of many people or processes payments,
• it contains a chatbot, an agent or other AI that reads foreign content or takes actions,
• your company may fall under the Cybersecurity Act or has customers who require it of you,
• you do not know how to answer more than three questions from the OWASP table.

If you found yourself in the second list, send us a few sentences about your app. We will get back to you with how we would proceed. Send an inquiry

How MeguMethod approaches it

When an app built with AI comes to us, we start with the same questions as in the OWASP table above. Architecture, security and code review are the technical guardrails we set in App as a Service before every launch: the first version is created with architecture, tests and deployment rules and goes straight to production. The result of the first pass is a list of what holds, what needs reinforcing and what can wait.

After that, every change you make to the app is checked by automation and by our engineers for security, architecture and function. The code stays yours and you get the tools and a guide to develop it yourselves. For companies where several people develop with AI, we handle the same at the level of the whole company: controlled deployment only to approved environments, central management of access and keys, and closed AI loops in which the model works only with data the company explicitly allows.

Next step

Do you have an app built with AI and want to know where it stands on security? See how App as a Service works, or book 30 minutes online and we will go through the seven flaws from this article on your app. If you want broader context first, read the checklist on whether your AI-built app is ready for real users, or the older text on whether to develop software with testers or without.