Skip to main content

Free · No signup · About 20 seconds

It works on your machine.
Let’s see what it does on the internet.

Vibe Check is a free security scanner for vibe-coded sites. Paste the URL of anything you built with Lovable, v0, Bolt, Replit, Cursor or Claude, and in about 20 seconds it checks the live site for API keys leaked into your JavaScript, Supabase service_role tokens the browser can read, downloadable .env and .git files, and missing security headers. It also measures speed, accessibility and whether Google can find you.

Then it does the part most scanners skip: it ranks the findings by what to fix first and estimates how long each one takes, so you get an afternoon's plan instead of a wall of red. No signup, no email, no install.

Public URLs only. We read what any visitor can already read: about 25 ordinary GET requests, roughly 20 seconds, nothing written to your site. We keep a record of the URL and its score. We do not log your IP address, and we never email you.

Why this page exists

Nobody argues about the cost of security until after they have paid it.

Getting something working is now the cheap part. A model will build you a functioning app in an afternoon, and that is a genuinely good thing. We use the same tools, and we ship faster because of them.

What the model does not do is the last ten percent, because nobody asked it to and nobody notices it is missing. Set a header. Move the key to the server. Turn on backups and then actually restore one. Give the form field a label. Return a real 404. None of it is interesting, none of it demos well, and all of it is the difference between a thing that works and a thing you can put a customer on.

That work has a reputation for being padding. It is not padding, it is the part that only looks optional. A key in a public bundle is not a code-quality opinion, it is your database. An untested backup is not diligence theatre, it is whether the business exists next Tuesday.

So: run your URL through this. If it comes back clean, you did the boring work and you should feel good about it. If it does not, at least now the list is specific.

The checklist

Everything it looks at.

Roughly fifty checks across five areas, weighted so that security counts for the most. Every finding comes back with what we saw, what to do, and an honest estimate of how long it takes.

Weighted heaviest

Security

The part that does not fail politely. It works right up until it is on Hacker News.

  • API keys, tokens and private keys sitting in the JavaScript your visitors download
  • Supabase service_role keys shipped client-side, which bypass row-level security entirely
  • A downloadable .env, .git directory, SQL dump, SQLite file or application log
  • HTTPS, the HTTP redirect, and HSTS
  • Content-Security-Policy, clickjacking protection, MIME sniffing, referrer and permissions policy
  • Session cookies missing HttpOnly, Secure or SameSite
  • Debug pages, stack traces and database errors printed to the public
  • Mixed content, forms posting over plain HTTP, wildcard CORS with credentials
  • Source maps, directory listing, and headers that publish your exact software versions

What it costs you in traffic

Speed

Every number here is a number a real person waits through on a phone, on a normal connection.

  • Time to first byte, measured, not estimated
  • Whether compression is even switched on
  • Total JavaScript the first page makes a browser download, parse and run
  • Render-blocking scripts and third-party origin sprawl
  • Cache headers on your static assets
  • Images with no declared size, which is where layout shift comes from
  • Lazy loading, responsive srcset, and whether anything is a modern format

The part everyone skips

UI and accessibility

Not a compliance checkbox. This is whether the thing is usable by people who are not you.

  • Viewport configuration, and whether you have disabled pinch-to-zoom
  • Alt text coverage across every image on the page
  • Form fields with no label, where placeholder text is doing a job it cannot do
  • Icon-only links and buttons with no readable name
  • Focus outlines removed with nothing put back, which strands keyboard users
  • A declared page language, and a sane heading structure

Whether anyone can find it

UX and findability

A product nobody can find, share or read is a private project with a domain name.

  • Title and meta description, including the framework defaults nobody changed
  • A stray noindex, or a robots.txt still blocking the whole site from staging
  • Open Graph tags, so shared links do not unfurl as a bare URL
  • Canonical URL, sitemap, robots.txt and real 404 status codes
  • Whether the content exists in the HTML at all, or only after JavaScript runs
  • A privacy policy, if you are collecting personal data without one

The day after launch

Reliability

Shipping is the start of the job. This is whether you will know when something breaks.

  • Error tracking, so a page that throws for a real user reaches you
  • Analytics, so decisions after launch are informed rather than guessed
  • A security.txt, so a researcher who finds a hole has somewhere to send it
  • Debug logging and TODO comments left in the production bundle

Being straight with you

What this cannot see.

A scan from outside catches the things that are visible from outside. That is a real and useful category, and it is not the whole job. Here is what we are explicitly not telling you, so a clean result does not give you the wrong idea.

Whether you have backups

Or whether anyone has ever restored one. An untested backup is a hope, not a plan, and it is invisible from outside.

Your database rules

We can see that a Supabase or Firebase key is public, which is normal. We cannot see whether row-level security is on behind it. That is the difference between a public key and a public database.

Your authentication logic

Whether a user can read another user’s data by changing an ID in the URL is the most common serious flaw in AI-built apps, and finding it means logging in as two people and trying.

What happens under load

Or when the payment provider times out, or when someone submits the form twice. Error paths are where products actually break, and they only show up when you go looking.

Rate limiting and abuse

Whether your signup form can be run ten thousand times tonight, and what that does to your model spend and your sender reputation.

Whether there are any tests

Or a staging environment, or a way to roll back. The question is not whether it works today. It is what happens the next time you change it.

Questions

The ones people actually ask.

Is this actually free, and do I have to sign up?

It is free and there is no signup. You paste a URL, you get the report on the page, and we never email you. To be straight with you about the trade: we do keep a record of each scan, which is the URL, the score, and which categories of issue came back. We do not log your IP address or anything that identifies you personally, and we do not store a copy of your page. We use it to see which builders produce which problems, and yes, occasionally to notice that someone who scanned a broken site might want help fixing it.

Is it safe to run this on my site?

Yes. The scan is about 25 ordinary GET requests for pages and files any visitor could already request, the same thing a search engine crawler does. Nothing is written, no forms are submitted, no logins are attempted, and there is no load worth noticing.

Will it show me my actual API keys?

No, deliberately. If we find a credential in your client-side code we show the kind of key and a masked fingerprint, never the value. Your secret should not travel through our logs or appear on your screen during a screen-share.

What if it says my site is fine?

Then the checks we can run from outside came back clean, which is worth knowing. It is not a certificate. Backups, database rules, authentication logic and error handling are all invisible from the outside, and they are where the expensive problems live.

Does using AI to build mean the code is bad?

No. We build with AI every day and ship faster because of it. The gap is not the code, it is everything around the code: the header nobody set, the key that ended up in the bundle, the backup nobody tested. Those steps get skipped because they are boring, not because a model wrote the function.

If the list is longer than your weekend

We do the unglamorous part for a living.

Champlin Enterprises builds and runs software that has to survive contact with real customers. Keys where they belong, headers set, backups tested, errors that reach a human. If you would rather hand the list to someone than work through it, that is the job.