Vibe coding: what it is, how it works and the hidden risks of AI-built sites

Two years ago, putting a web application online took weeks of work, some knowledge of HTML, CSS, JavaScript and maybe a backend. Today it takes a sentence in plain language and a few minutes. That's vibe coding: you describe to an AI what you want to build, and it generates the code, the interface and sometimes the infrastructure for you.

It's a real revolution, not a slogan. Thousands of indie hackers, solo founders and makers are shipping real products without ever opening a "proper" code editor. But there's a shadow side that gets little airtime: a site built with AI that "works" isn't automatically secure, or legally compliant. In this guide we look at what vibe coding really is, which tools people use, why it's so powerful and — above all — the three most common risks hiding under the surface of a vibe-coded product, and how to go from prototype to production without nasty surprises.

What vibe coding is

The term "vibe coding" became popular in early 2025 and describes a way of programming where the human no longer writes code line by line, but steers the AI with natural-language instructions, going with the "vibe" — the idea, the intent, the flow — rather than the technical details.

In practice it works like this: you open a tool, write "create a landing page for my fitness app with a signup form and a members' area", and the AI produces a working application. Then you iterate in words: "add Google login", "make the theme dark", "connect a database to store users". Each request changes the project in real time.

How it differs from traditional coding

In the classic model, the developer knows (or should know) every piece of the stack: how passwords are handled, where the secret keys live, which endpoints are exposed, how the server is configured. In vibe coding most of those decisions are made by the AI, often invisibly. The result arrives extremely fast, but it's also opaque: whoever "built" it frequently doesn't know what's under the bonnet. And it's exactly in that gap — between "what I see working" and "what actually happens" — that security problems nest.

How it works: the vibe coding tools

The ecosystem has grown fast. Here are the main players and what they do best.

The key difference: tools like Lovable, Bolt and v0 target people with little or no experience and aim to hand you a "ready" result, while Cursor assumes you can (at least somewhat) read code and acts as your copilot. Replit sits in the middle, offering both generation and hosting.

From here on we'll refer to them generically as vibe coding tools, because the risk pattern we'll look at is common to all of them: the AI generates working code optimised to show you a result, not necessarily to protect you.

The real benefits (which explain the enthusiasm)

Before the risks, let's be honest: vibe coding is powerful and its advantages are concrete.

• Speed. An MVP that used to take weeks now appears in an afternoon. For validating an idea, that's a paradigm shift.
• Accessibility. People with marketing, design or domain skills but no programming background can finally build their own product without finding (and paying) a developer.
• Low initial cost. A monthly subscription to an AI tool costs a fraction of a development team.
• Fast iteration. You try an idea, throw it away, try another. The cost of being wrong collapses.

For an AI MVP built to gather first feedback, all of this is gold. The problem starts when that prototype, unchanged, becomes the production product with real users, real data and — if you're in the EU — real legal obligations.

The hidden risks: "it works" doesn't mean "it's secure"

Here's the heart of this guide. Security in vibe coding is the great unsaid. The AI is trained to get you to a visible result: the page loads, the button works, the user signs up. But security is invisible by nature — you don't see it until someone exploits it.

A vibe-coded site can look perfect and, at the same time, have the database key written in plain text where anyone can read it. Let's look at the three most widespread flaws.

1. API keys exposed in the frontend

The classic number one. To get an integration with an external service working quickly — a database like Supabase, a payment service, an AI API, an email provider — the AI sometimes puts the access key directly in the frontend code, i.e. the part downloaded and executed in every visitor's browser.

The problem: anything in the frontend is public. Anyone who opens the browser developer tools (F12) can read that key. With an exposed secret key, an attacker can access your database, drain your credit on a paid service or send email in your name.

How to spot it

In the page source or in the network requests you see strings like sk_live_..., service_role, or parameters named api_key, secret, token. If you can see them in the browser, they're already compromised.

The rule is simple: secret keys belong only in the backend, never in code running in the browser. Only public keys, designed to be visible and protected by server-side access rules, may live in the frontend.

2. No rate limiting and endpoints without authentication

The second risk concerns your application's front doors, the endpoints (the URLs the frontend calls to read or write data).

Two typical problems of vibe-coded sites:

• No rate limiting. There's no cap on how many requests a single person can make. That opens you up to password brute-forcing (thousands of attempts a second), runaway costs if an endpoint calls a paid service, and plain outages from overload.
• Endpoints reachable without authentication. The AI creates an endpoint to, say, read a user's profile. In the rush to get the demo working, it doesn't add the check verifying who is asking. Result: anyone who knows the URL can get that data, without logging in.

Close relatives are the so-called guessable IDs in the URL. If your site shows an invoice at site.com/invoice/1043, what happens if a user changes the number to 1044? In a well-built app, the system checks that the invoice belongs to whoever requested it. In many vibe-coded apps it just shows it — exposing another customer's data. It's one of the most trivial vulnerabilities to exploit and one of the most common to find.

3. GDPR, cookies and privacy out of compliance

The third risk isn't technical but legal, and it's the one indie hackers underestimate most. If you have even one user in the European Union — and you almost always do — you're subject to the GDPR, wherever you happen to be.

A typical vibe-coded site launches with none of the legal requirements met:

• No privacy policy explaining what data you collect, why and for how long.
• No compliant cookie banner, or a banner that installs tracking cookies before the user has consented — which is exactly what the law forbids.
• No cookie policy and no terms of service.
• Forms collecting emails and personal data with no notice and no legal basis.

GDPR fines can be heavy, and for a small project even a complaint or a warning letter is a headache you don't need. If you take payments or sell online, the topic widens further: it's worth digging into our guide to GDPR for e-commerce. The point is that these documents aren't a detail to postpone: they're an integral part of a secure website that's also compliant.

Why AI generates insecure code (it's not a bug, it's an incentive)

It's worth understanding why this happens, because it helps you defend yourself. Vibe coding tools are optimised for a single metric: showing you something that works, as fast as possible. That's how they win you over.

Security, on the other hand, adds friction. Configuring authentication properly, handling keys in a backend, setting request limits, writing database access rules: all of these slow the demo down and, often, the user doesn't even ask for them. So the AI takes the shortest path. It isn't malice: it's the product's incentive. The result is that responsibility for security lands on you, who may not even know you're supposed to carry it.

From prototype to production: the checklist

The critical step is the one between "I have a working prototype" and "I'm opening it to the public". Here's a practical pre-launch checklist.

1. Move secret keys to the backend. No secret or service_role key should be readable from the browser. Use server-side environment variables.
2. Protect every endpoint. Every URL returning data must verify the identity of whoever is asking. No sensitive data without authentication.
3. Check data ownership. Before showing a resource (invoice, profile, order), verify it actually belongs to the authenticated user. Goodbye guessable IDs.
4. Set up rate limiting. Cap login attempts and calls to expensive endpoints.
5. Add security headers. Headers such as Content-Security-Policy, X-Frame-Options and Strict-Transport-Security shut down entire classes of attack and are often missing entirely from AI-generated sites.
6. Get the legal side in order. Privacy policy, cookie policy, banner with prior consent, terms of service.
7. Run a security check before going live. A test beats a discovery after the damage.

If you're wondering where to start with that last point, we have a dedicated guide on how to check website security step by step.

An order of priority

Not everything is equally urgent. If you're short on time, this is the sequence:

How to check your site in a few minutes

The good news is that you don't need to become a security expert to find these problems: most vibe coding flaws are recurring and recognisable. You can start manually, opening the browser developer tools and checking whether keys that look secret appear in the frontend, or trying to change an ID in the URL to see whether you get data that isn't yours.

If you'd rather have a complete picture without doing it all by hand, Appurai is a scanner built specifically for AI-made sites: it analyses your site automatically and flags keys exposed in the frontend, endpoints reachable without authentication, missing rate limiting, missing headers, guessable IDs and cookie and privacy problems. The free plan shows you which problems you have; the paid plans add guidance on how to fix them and can generate the legal documents for you (privacy policy, cookie policy and terms) to get you compliant. It's the quickest way to find out whether your prototype is ready for the public or whether it merely "works".

And if the worst has already happened, don't panic: read our guide on what to do if a site has been hacked.

Frequently asked questions

What is vibe coding in simple terms?

Vibe coding is a way of creating sites and apps by describing to an AI what you want to achieve, in natural language, instead of writing the code by hand. The AI generates the code and the interface for you, and you iterate in words. Tools like Lovable, Bolt.new, v0, Cursor and Replit make it possible to build a working product even without knowing how to program.

Are AI-built sites secure?

Not automatically. A site generated with AI can work perfectly and still have serious flaws, because these tools optimise for showing you a fast result, not for protecting you. The most common problems are API keys exposed in the frontend, endpoints without authentication and failure to comply with the GDPR. Specific checks are needed before going live.

What are the most common vibe coding risks?

The three most frequent are: secret (API) keys visible in browser code, endpoints reachable without login (including guessable IDs in the URL that expose other users' data), and the absence of compliance measures such as a privacy policy, cookie policy and a GDPR-compliant consent banner. Rate limiting and security headers are often missing too.

Do I have to comply with the GDPR if I built the site with AI on my own?

Yes. The GDPR applies based on who your users are, not how you built the site. If even one person in the European Union uses your service, you need a privacy policy, a cookie banner that asks for consent before installing tracking and, if you collect data, a valid legal basis. Having used an AI tool exempts you from nothing.

How do I know whether my API key is exposed?

Open your site, press F12 to open the browser developer tools and check the page source and the network requests. If you find strings starting with sk_live_, or containing secret, service_role or similar, that key is public and must be moved to the backend immediately and, where possible, revoked and regenerated. An automated scanner can find these exposures for you.

Can I launch an AI-built MVP without problems?

For validating an idea with a handful of trusted users, an AI MVP is perfectly fine. The delicate moment is when you open it to the public: before that step you should secure your keys, protect the endpoints, add rate limiting and sort out the legal side. A pre-launch security check stops a brilliant prototype turning into a data leak.

In summary

Vibe coding has democratised software creation: ideas that used to die from a lack of technical skills now become real products in an afternoon. That's a huge, positive change. But speed carries a hidden price: the tools that get you to a result quickly leave responsibility for security and compliance to you, and they do it quietly.

The difference between a maker who makes it and one who ends up in the press over a data leak isn't how much code they can write: it's whether they spent half an hour, before launch, checking that their "it works" was also an "it's secure". Do that check. It's the best-invested half hour of your entire project.