Vibe Coding Security

Security Layers

I vibe-coded my website — then built the security layers most people skip. What each one does, in plain English.

CA Gaurav K PatiyatBlog #1~4 min read
Flat illustration: a team securing a website — people with shields, locks, a secured screen, a laptop and a server.
In this post
Vibe coding security checklist (for non-coders)Common security mistakes in AI-coded appsHow to secure vibe-coded applicationsSecurity prompt to audit your app

A while ago, “build a website” sat firmly in the not-for-me column. I read balance sheets, not stack traces. Then I started experimenting with AI tools, and the distance between an idea and a live, working site collapsed to an afternoon. That’s what people mean by vibe coding: you describe what you want, you iterate, and the machine handles the syntax. For someone from finance, it’s genuinely liberating.

But I noticed something in all the vibe-coding excitement online. Everyone celebrates the shipping. Almost nobody mentions the securing. The screenshots stop at “it’s live.”

In audit we have a phrase: the numbers are always downstream of the controls.

A clean-looking P&L means very little if there’s no control environment behind it. Software is no different. “It works” is the output. Security is the control environment that decides whether you can still trust that output tomorrow. Skipping it doesn’t make you faster — it just turns visible work into invisible risk.

So once I’d built my site with AI, I spent real time on the unglamorous half: adding security. Here are the five layers I put in, in plain English — plus a sixth I’d add the day this site outgrows a free host. Pretending a personal site is a fortress would be the precise opposite of how a CA is trained to think.

Layer 01

An encrypted connection (HTTPS)

Locks the pipe between a visitor and the site, so nobody on the same network can read or quietly alter what’s sent. It’s the padlock in the address bar.

Layer 02

A strict code policy (Content-Security-Policy)

The browser is told exactly which code, styles and resources are allowed to run — mine, and a short, named whitelist — and to refuse everything else. If anything malicious were ever injected, it simply wouldn’t execute.

Layer 03

A spam-proofed contact form

A hidden “honeypot” field that only bots fill in, plus a timing check no real person trips. Junk gets dropped before it ever reaches my inbox.

Layer 04

Clickjacking defence

Stops someone secretly embedding my page inside theirs to trick visitors into clicking things they never meant to. If the page senses it’s trapped in a frame it doesn’t own, it breaks out.

Layer 05

Safe links & privacy

Outbound links can’t manipulate the tab they came from, and the site doesn’t leak its full address to the places it links out to. Small, but it’s basic hygiene.

BonusOne more layer
Layer 06 · the next level

Real security headers, for when you outgrow a free host

The five above are everything a free static host allows. The day this site moves to its own domain, routing it through Cloudflare’s free tier unlocks the headers GitHub Pages can’t send — HSTS (forces HTTPS, permanently), proper clickjacking protection, and protection against browsers mis-reading file types. All toggles in a dashboard, still no code. It’s the upgrade I’d reach for first.

A note on honesty

A static personal site has a small attack surface — no logins, no database, no payments. These layers are defence-in-depth and good hygiene, the same instincts a security-minded developer would apply. They are not “bank-grade,” and claiming otherwise would defeat the whole point.

Use this prompt

No coding required. Paste this straight into your AI tool to add the same layers to your own site:

You're a web-security expert. Harden the website I built with AI by adding the layers below. FIRST, before changing anything: scan my site and list every external thing it loads — fonts, scripts, stylesheets, images, and any form or API endpoints. My security rules must allow exactly those and block everything else. If a rule blocks something the site genuinely needs, the page breaks silently — so get this right up front. Add these security layers and keep everything copy-paste ready: (1) a Content-Security-Policy meta tag that only allows my own scripts, fonts, and form endpoint, and blocks everything else; (2) a hidden honeypot field plus a submit-timing check on my contact form to stop spam bots; (3) a clickjacking guard so my page can't load inside another site's frame; (4) rel="noopener noreferrer" on external links and a strict referrer policy; (5) A reminder to confirm HTTPS is on, and how to check it.; (6) if I move to a custom domain, route it through Cloudflare's free tier to add the security headers a static host can't send — HSTS, X-Frame-Options, X-Content-Type-Options. RULES: don't change how the site looks or behaves. Separate the changes you make in code from anything I have to do myself on my host or in a dashboard, and give me click-by-click steps for those. After each layer, give me confirmation.