We scanned our own production site and found 8 vulnerabilities. Here’s the list.

Building software in 2026 feels surreal. With LLMs handling boilerplate, we ship features in hours that used to take weeks.

But fast shipping has a nasty side effect: it breeds overconfidence.

A few days ago, we ran an automated check against our own live marketing site (vergate.dev). We build security and diagnostic tools for a living, so we expected a clean bill of health.

We were wrong. Our scanner flagged 8 real issues in production—including missing security headers that left us exposed to basic cross-site attacks.

Dogfooding your own tool isn't a marketing gimmick. Sometimes, it's just plain embarrassing. But it taught us a crucial lesson: you can’t fix what you don't automatically measure.

---

What our scan actually found

Here is the exact breakdown of what slipped past us into production (and what probably exists in your current deployment right now):

1. Zero Security Headers Enabled

Our hosting provider’s default CDN edge rules didn't set baseline headers. We were shipping without:

• Content-Security-Policy (CSP): Left us open to inline script injection.
• Strict-Transport-Security (HSTS): Didn't force browsers to enforce HTTPS strictly.
• X-Content-Type-Options: Allowed MIME-type sniffing on static assets.
• X-Frame-Options: Rendered our pages vulnerable to clickjacking IFrames.

Why this happens: Framework defaults (like Next.js, Nuxt, or Astro) often expect your proxy or CDN edge (Vercel, Cloudflare, Nginx) to handle headers. If you forget to configure the edge, your app runs bare.

2. Sensitive Meta & Server Leakage

Our response headers explicitly broadcast our server stack and proxy details. Attackers use automated scanners like Shodan or Censys to query these specific signatures and exploit target-specific CVEs in seconds.

3. Cookie Missing SameSite & Secure Flags

A tracking cookie set on a subroute wasn't explicitly flagged as SameSite=Lax or HttpOnly, leaving a window open for CSRF-style cross-domain requests.

---

How we fixed it (in under 10 minutes)

Fixing these issues wasn't complex—it was just easy to forget.

Instead of writing custom middleware for every header, we passed the scan findings context straight into our IDE:

• Edge Headers: Added a centralized header manifest in our deployment config to enforce HSTS and CSP globally.
• Cookie Sanitization: Updated our cookie handler to strictly attach Secure; HttpOnly; SameSite=Lax.
• Automated Gatekeeping: Wired the engine directly into our local setup so we can't merge broken configs to staging again.

---

Why "Vibe Shipping" Needs Automated Guardrails

When you’re moving fast or prompting AI assistants to generate full codebases, you review the UI, test the main user flow, and hit deploy. Nobody manually inspects raw HTTP response headers or cookie flags on every push.

If you want to read the full, unfiltered breakdown of our self-audit and what we learned about host edge defaults, check out our writeup: We scanned our own site and found real problems. Here's everything on the Vergate Blog.

Don't assume your deployment provider handles security defaults for you. Run a passive check on your app before your users—or an attacker—do it for you.

What’s the most embarrassing misconfiguration you’ve accidentally shipped to production? Let’s talk in the comments.