AI Website Security Checklist for Vibe-Coded Sites

Fast to build, easy to leak

AI-generated sites are useful because you can build them fast. That speed can also hide security problems. Common launch mistakes include exposed API keys, checks that run only in the browser, and forms without protection. Two more are private drafts that stay public and generated claims that nobody reviewed.

A vibe-coded website is a site that you build mostly by prompting an AI. This checklist helps you publish such a site safely, and it does not slow you down much. It works with any host. The examples cover Cloudflare Pages, Netlify, Vercel and GitHub Pages. If you do not have a host yet, the Netlify deployment guide is a good place to start.

1. Remove secrets before anything goes online

Do not publish private API keys, service keys, tokens, database credentials or .env files. A static host serves every file that you upload. Visitors can read any value that goes into the browser code (the JavaScript that the browser downloads and runs).

Search these places in the project for secrets:

  • .env files and config.* files
  • The bundled JavaScript in your build folder (dist, build or out)
  • Public JSON and CSV files
  • Copied terminal output and debug panels
  • Code comments that the AI left behind

Look at the prefixes of your environment variables. Build tools copy some variables directly into the browser code:

  • Vite bundles every variable that starts with VITE_ into the browser code. Never put a secret in such a variable (Vite env variables).
  • Next.js puts every variable that starts with NEXT_PUBLIC_ into the JavaScript that it sends to the browser (Next.js environment variables).

Some keys are public by design, and other keys are not. Supabase is a common example in AI-built apps. Its publishable (anon) key is safe in a web page. Row Level Security (database rules that control access to each row) limits what that key can reach. The secret (service_role) key bypasses Row Level Security. That key must never leave your server (Supabase API keys).

Some sites use a secret key to call an AI API, a payment API, a database or an email service. Move each such call to server-side code, for example a Cloudflare Pages Function, a Netlify Function or a Vercel Function. Store the key as a secret in the settings of the host.

If you keep the code on GitHub, push protection can block a push that contains a secret. It stops the push before the secret gets into the repository.

2. Do not trust the browser

Checks in the browser make the site easier to use, but they do not give security. Anyone can change requests or page scripts in their own browser. Do each important check on a server or with platform rules.

Review these parts of the site:

  • Form validation
  • Sign-in and permission checks
  • Database access rules (for Supabase, Row Level Security policies on every table)
  • Limits on file uploads
  • Admin-only actions
  • Paid or private content

AI tools often add a password prompt to the JavaScript of the page. This prompt does not protect anything. The “hidden” content is already in the files that the browser downloaded. Use the access control of your host instead (see the next step).

3. Keep the draft private during review

Use a private-first workflow. In this workflow, the site stays behind real access control until you finish the review. This is most important when the site contains:

  • Client data
  • Internal plans
  • Early product messaging
  • Unreleased pricing
  • Generated reports
  • Prototype app behavior

The options for a private review are different for each host:

Host Private review option Notes
Cloudflare Pages Cloudflare Access, with sign-in by a one-time code for the email addresses that you allow Turn on Enable access policy in the project settings. Then extend the policy to the pages.dev domain. See our Pages access guide
Vercel Deployment Protection with Vercel Authentication Available on all plans. Reviewers need a Vercel account or a shareable link (Vercel Authentication)
Netlify Site-wide password Pro and Enterprise plans only
GitHub Pages None for typical accounts Sites are public even from private repositories. Do the review on a different host first

If a review copy must stay public, keep it out of search results at a minimum. On Cloudflare Pages, a _headers file can add an X-Robots-Tag: noindex header to the pages.dev addresses (Pages headers).

4. Rate-limit and verify risky flows

For generated forms, signups, uploads, comments or notifications, find out how the site prevents abuse.

These controls are useful:

  • Rate limits (a maximum number of requests in a time period) that fit the use case. If your domain is on Cloudflare, rate limiting rules can limit the requests to a form or a login path.
  • Email verification for new accounts.
  • A CAPTCHA or a honeypot field (a hidden field that only bots fill in) on public forms. Cloudflare Turnstile works on any site if the server checks each token. See our Turnstile setup guide.
  • Server-side validation of every field.
  • Logs of rejected and suspicious submissions.
  • Notifications to the owner for new submissions, so that the owner sees abuse early.

Be careful with rules that use only the IP address. They can block shared office networks or mobile networks, and they can still miss determined abuse. The correct limit depends on the audience and the risk.

AI-generated sites often contain placeholders that look real. A safe publish therefore includes a review of the content. Make sure that these items are correct:

  • Source links (do they exist, and do they say what the page claims?)
  • Facts and metrics
  • Customer names and logos
  • Product claims
  • Legal, medical or financial statements
  • Prices and dates
  • Downloadable files

A made-up testimonial or a wrong price causes a trust problem, even if the code is fully secure.

6. Publish, watch traffic and keep an update path

When the review is done, change the site to its final access setting. Then publish the site. After that, monitor it:

  • Turn on simple analytics. For a Pages project, you can turn on Cloudflare Web Analytics in the Metrics tab of the project (Web Analytics). Other hosts have similar options.
  • Look for unexpected paths, unusual traffic sources and form submissions that look automated.
  • Look at the usage dashboards of your AI provider and your database provider in the first days. A sudden spike can mean a leaked key.

Keep the source folder and your prompt history, if possible in a Git repository. Then you or an AI agent can fix problems and redeploy to the same project. Keep the previous working build until you make sure that the new build works.

Vibe coding publish checklist

Before and after you publish, make sure that these statements are true:

  • The published files and the public build variables contain no secrets or private keys.
  • Screenshots, test fixtures (sample data for tests) and JSON files contain no private data.
  • Important checks run on the server or in database rules.
  • You chose the access setting on purpose. The private review uses the access control of the host, not a JavaScript prompt.
  • Forms and signups have protection against abuse and server-side validation.
  • Links, facts, names, prices and claims are correct.
  • The mobile layout and the desktop layout work.
  • After you share the site, you review the analytics and the usage at your providers.
  • You saved the source folder for updates, and you kept the last working build.

Takeaway

A vibe-coded site is not reckless if you follow a practical publish checklist. Keep secrets on the server. Keep the draft behind real access control until you finish the review. Protect the forms. Make sure that the content from the AI is correct. Redeploy fixes to the same project.

A docs portal with Ask AI
and support tickets

Connect a repository, or describe your product to start. Each docs site has search, Ask AI, an API console, an MCP server and support tickets.

  • Publishes from GitHub on every push
  • Works with Mintlify repositories
  • API console from your OpenAPI file
  • MCP server and llms.txt for AI agents
  • Ask AI and support tickets
  • Analytics for people and AI agents
Start Free Questions? Ask AI in our docs

No card required.

Frequently Asked Questions

What should I do if a secret key was already published?

First, revoke or rotate (replace) the key at the provider. It is not enough to delete the file, because copies can stay in caches, in the Git history and in forks. Then move the call to server-side code. Store the new key as a secret in the settings of the host. Redeploy the site. Then look at the usage and the logs at the provider for misuse.

Can I ask the AI that built the site to review its own security?

Yes, as a first pass. Ask it to list every secret, every browser-only check and every public form. Also ask it to explain how the site protects each one. Then make sure yourself that the answers are correct, in the deployed files and in the settings of the host. The same assistant can repeat its own blind spots.

Share:
Markdown version

Related Articles

↧
Loading PDF…