AI Website Security Checklist for Vibe-Coded Sites
Table of Contents
- Fast to build, easy to leak
- 1. Remove secrets before anything goes online
- 2. Do not trust the browser
- 3. Keep the draft private during review
- 4. Rate-limit and verify risky flows
- 5. Review links, data and generated claims
- 6. Publish, watch traffic and keep an update path
- Vibe coding publish checklist
- Takeaway
- Fast to build, easy to leak
- 1. Remove secrets before anything goes online
- 2. Do not trust the browser
- 3. Keep the draft private during review
- 4. Rate-limit and verify risky flows
- 5. Review links, data and generated claims
- 6. Publish, watch traffic and keep an update path
- Vibe coding publish checklist
- Takeaway
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:
.envfiles andconfig.*files- The bundled JavaScript in your build folder (
dist,buildorout) - 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.
5. Review links, data and generated claims
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
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.
Related Articles

Add a Custom Domain to a Cloudflare Pages Site
Add a custom domain or www to a Cloudflare Pages site: set it up in Pages first, add the DNS record, fix stuck verification and redirect www.

What Is localhost:3000?
Your browser uses localhost:3000 to reach an app running on your own computer. Sending that address to someone else does not give them access to your app.

Move Exported Grok Website Files to Another Host
Export a Grok Build site to GitHub, deploy it on Cloudflare Pages, Netlify, Vercel or GitHub Pages, test it, then retire the grok.me copy.