Are AI-Built Websites Actually Less Secure? What The Data Shows

The short version: not every AI-built website gets hacked, and we are not going to claim otherwise. What the evidence actually supports is narrower and more useful: independent security testing puts AI-generated code's security pass rate at roughly 55 percent, and public scans of live AI-built sites and apps have repeatedly found the same specific failures — exposed API keys, broken access control, SQL injection — at a scale large enough to be a pattern, not a coincidence. That is the claim this article makes, and it is the one the data supports.

We build Webflow sites for a living, so say the conflict of interest out loud: we have a commercial reason to want this to be true. What follows is not our opinion. It is named research, named public vulnerability scans, and one well-documented public incident, with sources you can check yourself.

First, Which "AI-Made Website" Are We Talking About?

This matters more than it sounds like it should, because the actual risk is very different depending on the answer, and lumping every AI-adjacent tool together is how these arguments get sloppy.

• Template AI site generators — Wix ADI, Durable, GoDaddy Airo. You describe a business, the tool assembles a site from its own templates on its own infrastructure. Wix or Durable hosts everything, controls the backend, and owns the database. There usually is no custom backend for a business owner to expose.
• AI code generation — "vibe coding" — tools like Lovable, v0, Cursor, bolt.new, or a business owner simply asking ChatGPT to write and deploy a working site with a database, login, or payment flow. This is where the site's actual server logic, database queries, and API integrations are generated by the model, then shipped with little or no security review.

The research below is almost entirely about the second category, and that distinction matters because increasingly, "I asked AI to build me a website" means the second thing, not the first — the moment a site needs a contact form that saves to a database, a login, a booking system, or any payment integration, it has left template territory and become a custom application that happens to have been written by a model instead of a person.

What The Testing Actually Found

Veracode's 2026 GenAI Code Security Report tested current-generation models — including the latest releases from every major vendor — by having them write code and then scoring it against real security tests. The average security pass rate came out to roughly 55 percent, barely moved from the prior year's report. Put plainly: close to half of the code these models produce fails a basic security check, even though the code runs and looks correct.

One pattern stood out. When asked to defend against cross-site scripting — a vulnerability class that has been well understood and well documented for over two decades — the models failed in 86 percent of relevant test cases. This is not an obscure edge case models have never seen; it is one of the most publicly documented vulnerability types that exists, and the failure rate was still that high.

A separate empirical study across Fortune 50 engineering teams found that developers using AI assistance shipped code three to four times faster than their peers — but introduced security findings at ten times the rate. Speed went up. So did the defect rate, disproportionately.

What Shows Up When Real Sites Get Scanned

Lab tests are one thing. What happens when researchers scan AI-built sites that are actually live is the more convincing evidence, because these are not hypothetical vulnerabilities — they are open doors on real, deployed applications.

• Escape.tech scanned 5,600 publicly deployed AI-generated applications and found roughly 2,000 highly critical vulnerabilities, 400 instances of exposed secrets — API keys and access tokens sitting in plain text — and 175 instances of exposed personal data, including medical records and payment information.
• Red Access scanned over 5,000 live AI-generated apps and found that close to 40 percent exposed sensitive data of some kind.
• Across seven separate documented incidents in 2025 and 2026, AI-generated applications collectively exposed an estimated 1.5 million API keys, granted unauthenticated access to private enterprise data, and in one case wiped a production database entirely.

These are not four different opinions about AI code. They are four independent groups scanning real, deployed applications and finding the same categories of failure.

A Named Example, Because "Reportedly" Isn't Enough

In 2025, the Tea app — built substantially with AI-assisted code generation — exposed users' private direct messages to other users, due to a broken access control check the AI generated without anyone catching it in review. This was widely reported at the time and is a matter of public record, not an anonymous anecdote. It is also a useful illustration of the actual failure mode: not some exotic attack, but a basic permission check that should have stopped one user from reading another user's private messages, and didn't, because nobody who understood access control looked at that code before it shipped.

Why This Keeps Happening: Two Specific, Explainable Patterns

This is not "AI is bad at coding" in some vague sense. Both of the most common failure types have a clear, specific mechanical cause.

Hardcoded API Keys

Putting a secret key directly into the code the browser downloads is the fastest way to make a demo work — and demos are what these models are, in effect, optimizing for. Moving that same key to a server-side environment variable requires understanding a deployment context — where the code will actually run, what has access to it, what is public and what isn't — that the model generating the code does not have visibility into. So it takes the path that works immediately, and the key ends up sitting in plain text in a JavaScript file anyone can view. One documented case involved a key hardcoded into an AI-built landing page that sat there, unrotated, for three years, because nobody knew it was there to rotate.

SQL Injection

The safe way to query a database is a parameterized statement, where user input is passed as data, never as part of the query text itself. The unsafe way concatenates user input directly into a SQL string. Models trained on a large historical corpus of code — much of it written before parameterized queries became the settled standard — reproduce the older, unsafe pattern by default unless a prompt specifically asks for the safe version. Nobody chose this outcome; it is simply what the average of publicly available training code looks like, reproduced faithfully.

Both patterns share the same root cause: the model was never taught to ask "what happens if this is attacked," because generating working code and generating secure code are different problems, and only one of them is what "does this run" actually tests for.

Where This Argument Does Not Apply

To be fair in the other direction: a template AI site generator with no custom backend — a Wix ADI or Durable site with no login, no database, no payment integration — does not carry the SQL injection or exposed-secret risks described above, because there is no custom server code for those failures to live in. Its risk profile is different: it inherits whatever the platform itself gets right or wrong, and every other site on that platform shares the same exposure if the platform is ever compromised. That is a real risk, but it is not the one this article's evidence is about, and conflating the two would be dishonest.

The actual dividing line is not "did AI touch this website" — it is "does this website have a custom backend that a model wrote without security review." Increasingly, when a small business asks an AI tool to build them a real, functioning site, that is exactly what they get.

Where Webflow Sits, And Where It Doesn't Get A Pass

Webflow removes an entire category of this risk by construction, not by promise: it hosts the server and database itself, so there is no custom backend code, no database connection string, and no API key sitting in a business owner's own JavaScript bundle for any of the scans above to find. That is a structural difference, not a marketing claim — the vulnerability classes documented here need a custom backend to exist in, and a standard Webflow site does not have one.

That is not the same as saying a Webflow site is immune to everything. A weak account password, an unreviewed third-party embed, or a misconfigured form integration can still create real problems on any platform, human-built or not. The honest claim is narrower than "Webflow is unhackable": it is that a specific, well-documented, currently surging category of vulnerability — the one in every scan cited above — requires a custom AI-generated backend to exist, and most business websites do not need one badly enough to accept that risk.

A Two-Minute Check You Can Run On Any Site

This works on your own site, a competitor's, or anything an AI tool built for you — and you do not need any security background to run it:

• Open the site in a browser and open Developer Tools (F12, or right-click → Inspect).
• Go to the Network tab, then reload the page.
• Use the filter or search box for the terms key, token, or secret across the requests and any loaded .js files.

If a real credential shows up in plain text in anything your browser downloaded, so has everyone else's — it is public the moment the page loads, regardless of how the login screen looks. If you find one on a site you control, rotate it immediately and move it server-side before doing anything else.

What This Means If You're Deciding How To Build

For a quick prototype nobody depends on, with no real user data and no payment flow, the risk described here is close to irrelevant — there is nothing sensitive to expose. That case still exists and we said so plainly in our earlier comparison of Webflow against AI website builders.

The calculus changes the moment a site collects customer information, handles a login, or touches payment — which describes most real business websites. At that point, "was this security-reviewed by someone who understands access control and injection risk" stops being a nice-to-have question and becomes the question, and the data above is a straightforward answer to whether AI-generated code has reliably had that review: on current evidence, usually not.

If you're evaluating a custom AI-coded build against a platform like Webflow, our Webflow website development service is built around exactly this trade-off — and if you've already got an AI-built site and want a second opinion on what it's actually exposing, that conversation costs nothing to start.