"Vibe coding," no-code builders, AI copilots that write your backend in one prompt — building a website or an app has never been this fast. Ask an AI assistant for a booking form, a payment integration or an admin panel, and you'll have working code in minutes. The problem is that "working" and "secure" are two very different things. Speed hides risk, and the risk doesn't show up until it's already a problem: a leaked key, an indexed conversation, an unpatched vulnerability quietly sitting in production.

This isn't a reason to avoid building with AI — it's a genuinely powerful way to move faster. But it comes with a category of security issues that matters more now than before. Understanding them is the first step to avoiding them.

AI-generated code isn't secure by default

An AI code generator optimizes for one thing above all: producing code that works. It rarely optimizes for code that resists attacks. The result is that AI-assisted projects often ship with the same classic flaws that security audits have been flagging for twenty years — just produced faster, and at greater volume.

The most common issues we see in AI-built sites and apps:

  • Cross-site scripting (XSS) and injection flaws — user input rendered or queried without proper sanitization, opening the door to script injection or database manipulation (SQL injection).
  • Missing or weak input validation — forms, API endpoints and file uploads that trust whatever the client sends, instead of checking it server-side.
  • Unvetted dependencies — AI tools happily suggest npm or PHP packages to "save time," some outdated, poorly maintained, or with known vulnerabilities never checked before being added to the project.
  • Overly permissive defaults — open CORS policies, admin routes without authentication, database rules left wide open "to make it work," and never tightened afterward.

None of this is unique to AI — human developers make the same mistakes. The difference is volume and speed: a non-technical founder can now generate and deploy an entire application in a weekend, with no security review step anywhere in the process. That's where the exposure comes from.

API keys: the most common leak

If there's one issue we find on almost every AI-built site we audit, it's this: an API key sitting somewhere it should never be. It happens in three recurring ways.

  • Hardcoded in the front-end. An AI assistant writes a snippet that calls OpenAI, Stripe, Google Maps or a CRM directly from the browser, with the key pasted straight into the JavaScript. Anyone can open developer tools, look at the source or the network tab, and copy that key in seconds.
  • Pushed to a public GitHub repository. A project starts as a private experiment, gets pushed to GitHub for convenience, and the repository — with its `.env` file or its key committed in plain text — turns public, sometimes without anyone noticing. Bots scan GitHub for exposed keys around the clock.
  • Copied as-is from an AI conversation. The AI generates a working example with a placeholder key, or worse, reuses a real key pasted earlier in the conversation, and it ends up shipped without a second look.

The consequences are concrete, not theoretical. A leaked OpenAI or cloud API key can be used by someone else to run their own workload on your account, generating a bill that can reach thousands of euros within hours. A leaked Stripe or payment key can expose transaction data or allow abuse. A leaked database or backend key can mean direct access to your customers' personal data — a GDPR incident, not just a technical one.

An API key must never live in client-side code (front-end, mobile app, anything running in the user's browser) and must never be committed to a public repository. It belongs on the server, in an environment variable, outside version control.

Your AI conversations can end up on Google

Fewer people think about this one, but it deserves the same level of attention. AI assistant conversations aren't automatically private forever. Shared conversation links from several popular AI tools have already been found indexed and searchable on Google — meaning anyone could stumble onto them through a simple search. Some browser extensions and third-party integrations also transmit prompt content in ways users don't fully control.

Now think about what actually gets pasted into those prompts during a typical AI-assisted build: full code files, database schemas, real API keys "just so the AI understands the context," customer email lists for a test import, sometimes even login credentials. If that conversation is ever shared, cached, or indexed, all of it becomes exposed — with your name or your company's name potentially attached to it.

The rule here is simple and worth repeating to anyone on your team who uses AI tools: never paste passwords, API keys, credentials or real customer data into a public AI assistant. Use placeholders, dummy data, or redacted examples instead. If the AI needs to understand a data structure, describe it — it rarely needs the real values.

How to secure your AI-assisted builds

None of this means AI tools should be avoided — it means they need the same security discipline as any other development process, adapted to how fast things move. Here's what a secure AI-assisted project looks like in practice.

  • Keep every API key and secret server-side, in environment variables or a `.env` file that is explicitly excluded from version control (`.gitignore`).
  • Rotate any key that has ever been pasted into an AI prompt, a public repo, or shared with anyone outside the project — even "just in case."
  • Have a human review AI-generated code before it goes to production, focusing on authentication, data access, and anything that touches user input.
  • Enforce HTTPS everywhere, with proper security headers (CSP, HSTS, X-Frame-Options) on every environment, not just production.
  • Apply the principle of least privilege: each API key and each service account should only have the permissions it strictly needs.
  • Never paste a real secret, credential or customer record into a public AI prompt — use placeholders instead.
  • Check GDPR compliance for any personal data your AI-assisted app collects, stores or transmits, including through third-party APIs.

Inherited a site built with AI — by an intern, a freelancer, or yourself in a rush? It's worth a dedicated pass to check for these exact issues. Pair it with related checks: our articles on WordPress, CMS and custom project security and server security audits cover the infrastructure side, while our website & SEO audit looks at performance and visibility. Ongoing protection also depends on regular updates — see our website maintenance plans.

Not sure what your AI-built site is exposing?

We run a free security check on exposed API keys and secrets, HTTP security headers, known vulnerabilities in your dependencies and CMS, and your overall server and site configuration. You get a clear report — no jargon, no pressure — with what to fix first.

Get my free security audit

FAQ

Is a website built with AI less secure?

Not necessarily, but it is more exposed if the code isn't reviewed. AI code generators produce functional code fast, but they don't guarantee it follows security best practices: input validation, protection against injections, safe handling of secrets. Without a human review pass, vulnerabilities that would be caught in a traditional development process can slip straight into production.

How do I know if my API key leaked?

Check your provider's usage dashboard (OpenAI, Google, Stripe, AWS…) for unexpected spikes in calls or billing. Search GitHub and public code search engines for your key's exact string. Also inspect your website's front-end source and network requests in the browser: if a key appears there in plain text, it is exposed to anyone who opens developer tools.

Are my ChatGPT chats public?

By default, no. But shared conversation links, some browser extensions, and certain sharing settings have already caused AI assistant chats to appear in Google search results. Treat anything pasted into a prompt — secrets, code, personal data — as potentially exposed, and never paste passwords, API keys or customer data into a public AI tool.

What to do if I exposed an API key?

Revoke and rotate the key immediately from the provider's dashboard, even if you're unsure it was actually used. Check the usage logs for suspicious activity. Remove the key from your code and your git history (deleting it in a new commit isn't enough, it stays in the history). Move it to a server-side environment variable, outside any public repository.

What's in the security audit?

We check for exposed API keys and secrets (front-end, repository, network requests), HTTP security headers, known vulnerabilities in your dependencies and CMS, server and site configuration, and GDPR/data-handling compliance. You receive a clear report with a prioritized action plan.