Website security

The security checklist for vibe-coded websites

A practical pre-launch pass for sites built quickly with AI: the checks that catch public mistakes without turning the project into a month-long audit.

1 August 2026 · 6 min read

A vibe-coded website usually has one strength and one weakness: it exists. That matters more than people admit. But the same speed that gets a landing page online can skip the quiet production details that protect visitors and prevent embarrassing scans later.

This is the short version of a pre-launch pass. It is deliberately not a full audit — it is the set of things that are cheap to check, cheap to fix, and expensive to be caught by.

Start with transport and TLS

HTTPS should redirect cleanly from HTTP, the certificate should be valid and not close to expiry, and HTTP Strict Transport Security should be present once you are confident the domain is HTTPS-only.

HSTS is worth understanding before you enable it, because it is deliberately hard to undo. A browser that has seen the header will refuse plain HTTP for the duration you specified, which is exactly the point and exactly the risk.

Then the browser protections

Content Security Policy, frame protection, MIME sniffing prevention, referrer policy and permissions policy are all single response headers, and the response either contains them or it does not. There is no partial credit and no ambiguity.

Start narrow on CSP and tighten from there rather than pasting a maximal policy from a blog post. If you want an agent to write it, give it evidence and constraints rather than an instruction to make things secure.

Look for accidentally public files

A surprising number of generated sites serve old build artifacts, source maps, backup files, framework defaults, or an environment file that was only ever meant to exist locally.

Single-page apps hide this well, because they return the same HTML for every path — so a naive check reports every guessed filename as exposed. A good scanner distinguishes a real file from an index fallback before it raises a critical. More on that in exposed env files.

Finish with discoverability

If the site should be indexed, do not ship noindex. It is the single most common launch mistake, and it usually arrives from a template or a preview deployment that nobody re-checked.

Then make the crawler posture deliberate. Whether AI assistants should be able to read and cite you is a business decision, not a default to inherit from whatever robots.txt your scaffold generated.

Common questions

How long should a pre-launch security check take?

The external pass described here takes seconds to run and usually under an hour to act on. It is designed to fit before a launch rather than to replace a proper review afterwards.

What is the most common mistake on a new site?

A leftover noindex directive, closely followed by missing security headers. Both are invisible in the browser, which is exactly why they survive to production.

Do static sites need security headers?

Yes. A static site can still be framed, can still leak referrer data to third parties, and can still serve a file it should not. Headers cost nothing to add and remove entire categories of problem.