Built with AI, shipped in a weekend: what to check before a vibe-coded site goes live

AI app builders such as Lovable, Bolt, v0 and Replit have changed who ships websites. A founder, a marketer or a small business owner can describe what they want and have a working app with a database and a login in an afternoon. That is genuinely useful. It also means a lot of software now reaches production without anyone who would recognise its security mistakes looking at it.

The mistakes are recognisable. They show up again and again, and most of them are visible from outside without any access to the code. If you build, review or maintain these sites, this is the checklist to run before launch.

1. Secrets in the JavaScript bundle

Everything a browser downloads can be read by whoever downloads it. When a builder wires up a payment provider, an email service or an AI API, the key sometimes ends up in client-side code, where every visitor receives it.

What to check:

• Search the built JavaScript for key formats from the services the app uses. Secret keys often have recognisable prefixes, such as sk_live_ for Stripe secret keys.

• Distinguish publishable keys, which are designed to be public (a Stripe publishable key, a Supabase anon key), from secret keys, which must never leave the server.

• If a secret key is exposed, revoke and replace it. Removing it from the code is not enough, because the old key is already public.

Our free exposed API key checker reads a site's bundle and matches it against the credential formats of the major providers.

2. A database anyone can read

Supabase is the most common backend for AI-built apps, and it works a particular way. The app ships a public "anon" key on purpose: it identifies requests but authorises nothing on its own. Row-level security (RLS) is what decides who can read which rows. With RLS off, which is the default for a table created with SQL rather than in the dashboard, that public key can read every row in the table.

AI builders are good at creating tables and less reliable at adding the policies. The app works perfectly in the demo, and the customer table is readable by anyone who looks.

What to check:

• RLS is enabled on every table that holds anything other than genuinely public data.

• Each table has policies that match who should read and write it.

• Test as an anonymous user: a request with only the anon key should return nothing from a private table.

The free Supabase RLS checker reads the public key from a site's own bundle and makes read-only requests against common table names. It never writes, changes or deletes anything.

Firebase and other backends have the equivalent problem through their security rules. The principle is the same: public identifiers are fine; missing authorisation is not.

3. Source maps in production

A source map lets developer tools turn minified JavaScript back into the original source, with file names, comments and structure. Useful in development; in production it hands anyone a readable copy of your front-end code, including any logic or comments that were never meant to be public.

What to check: request the .map files referenced at the end of the production bundles. If they load, turn source map generation off for production builds, or keep them private. The source map checker does this for free.

4. Security headers

Generated apps frequently ship with no security headers at all. At minimum, add Strict-Transport-Security, X-Content-Type-Options, a framing policy and a Referrer-Policy, and work towards a Content-Security-Policy. Most hosting platforms let you set these in a config file.

5. Placeholder content and scaffolding

Lorem ipsum in a footer, a "Your Company" logo, a demo testimonial, an example email address in the contact section. These are not security problems, but they are what visitors and prospects notice first, and they signal that nobody reviewed the site before launch.

6. Can search and answer engines read it?

Many generated sites render almost everything with JavaScript, ship without a proper title or description, and sometimes carry a robots.txt that blocks crawlers. Check that the important pages have real titles, meta descriptions and headings in the served HTML, and that robots.txt allows the crawlers the business wants. We wrote about the AI side of this in how to check robots.txt for AI crawlers.

7. Which builder and host

Knowing what built the site and where it is hosted tells you where each fix goes: the builder's settings, the hosting platform's headers file, or the backend's dashboard. It also lets you explain findings in terms of the tool the owner actually used.

Explaining it to the person who built it

The builder of a vibe-coded site is often not a developer and may be defensive about it. Keep the tone practical:

The app works well. Two settings that the builder does not switch on by default need changing before real customer data goes in: the database needs access rules on the customers table, and the payment key needs to move to the server. Both are an hour's work.

Framed that way, the audit is help, not criticism.

Stay read-only

Everything above can be checked without logging in, submitting anything or writing to the database. If a check finds an exposure, confirm it is reachable and stop there. Our guide to passive website security checks sets out where the line is.

SiteAssay checks for exposed keys, readable Supabase tables, public source maps, missing headers and leftover placeholder content as part of a full audit, and fingerprints the builder and host separately. You can try the fast checks with a free website audit.