Two months ago I shipped UNPWNED, a passive web security scanner aimed at indie hackers and developers shipping AI-generated code (Cursor, Lovable, Bolt, Replit, v0).

I had a hypothesis: small-team apps, especially anything coded with AI assistance, would have terrible security hygiene. Not because the developers are lazy, but because nobody is checking. There is no security review when you ship at 2am from your bedroom.

Two months in, 548 developers ran 1,317 scans through it across 596 distinct domains. The scanner logged 10,577 findings.

The data is worse than I expected.

This post is what I found. Not opinions. Not vibes. Real numbers from real production sites people own.

The headline numbers

Across every distinct domain scanned, deduplicated to the latest scan per site, here is what is exposed:

• 92.6% have no DNSSEC. Their entire domain can be DNS-spoofed at the resolver layer.
• 81.6% have no rate limiting anywhere. Anyone can run an unlimited brute-force against them right now.
• 78.5% have no DKIM. Email signing is missing, so domain spoofing is much easier.
• 69.6% have no discoverable privacy policy at standard paths. That alone is a GDPR violation in the EU.
• 66.9% are missing a Content-Security-Policy header. One stored XSS and the attacker has full control of the page.
• 52.7% have no DMARC policy. Their email domain can be impersonated for phishing at scale.
• 43.3% have no SPF record either, finishing the email-impersonation hat trick.
• 99.7% have no security.txt (RFC 9116). When a researcher finds a bug, there is nowhere to send it.

For comparison, here is what they actually got right:

• 100% of sites where SSL was measurable had valid SSL/TLS. Good. Let's Encrypt did its job.

The average security grade across all sites: 70.8 out of 100. A pass on a college midterm. A fail on a production checklist.

Why this is worse than it sounds

A "missing security header" sounds boring on paper. Here is what it actually means:

No rate limiting on /api/auth/login: an attacker takes a leaked credential dump from another breach and replays it against your site at 1,000 attempts per second. If even 0.1% of your users reuse passwords (the real number is closer to 60%), the attacker is now logged in as your users.

No CSP: your site has a single XSS bug somewhere, anywhere. A user comment, a markdown field, a profile bio. Without CSP, the attacker injects <script src="evil.com/x.js"> and now they read every keystroke, every session token, every form value. With CSP set correctly, the script never runs.

No DMARC: I send an email from support@yourcompany.com to all your users with a "verify your account" link that goes to my phishing page. Your mail server has no policy telling Gmail to reject it. Gmail delivers it.

No DNSSEC: your DNS resolver answers yourapp.com and points to 1.2.3.4. An attacker on a compromised network can poison that response and point to 6.6.6.6 instead. Without DNSSEC the resolver has no way to verify the answer is authentic.

These are not theoretical. These are the attacks that already happen every day to small SaaS, and the population running without protection is the majority.

The case I will not forget

Most of what UNPWNED finds is configuration drift. Boring. Fixable in 5 minutes once you know.

But one site stood out.

A user submitted a real production domain for a deep scan. The site looked completely normal in a browser. Generic landing page, a few links, nothing weird.

UNPWNED's cloaking detector compares what a real visitor sees against what Googlebot sees. The two should be identical. They were not even close.

To a human visitor: a normal page.
To Googlebot: roughly 64,000 spam pages selling counterfeit collectibles.

The site had been compromised in a Japanese SEO Hack pattern. The attacker had injected sub-sitemaps that were only served to crawlers, then mounted ghost URLs that returned 404 to people but 200 to Google with full spam content. The site owner had no idea. Their actual product was clean. The attacker was using their domain authority to rank spam, completely invisibly.

We caught it because the scanner samples ghost URLs from sub-sitemaps and compares User-Agent responses. 75 sub-sitemaps was a red flag (anything over 20 is suspicious). The spam keywords in the sub-sitemap titles were the smoking gun.

If you have ever wondered "why is my Google traffic dropping for no reason," this is one of the answers nobody mentions.

What is going wrong

Three patterns explain almost everything I see:

1. AI-generated code skips the boring parts.
When you ask Cursor or Claude to "build me a login form," it builds a working login form. It does not build rate limiting. It does not set up CSP. It does not configure DMARC. Those are runtime concerns, not code concerns, and the AI tools live in code.

2. The default of every framework is insecure.
Next.js, SvelteKit, Astro, Nuxt. None of them ship with a real CSP. None of them rate-limit by default. The defaults assume you will configure security yourself. Most developers do not.

3. Hosting platforms hide the gaps.
Vercel and Netlify give you free SSL, free deploys, free domains. Beautiful. They do not give you free rate limiting, free CSP, or free DMARC. The gap between "deployed" and "secure" is invisible until you scan for it.

How to fix the four most common ones in under 30 minutes

I am going to give you the actual code. Take it.

1. CSP header (Next.js example)

In your middleware.ts or proxy.ts:

const cspHeader = `
  default-src 'self';
  script-src 'self' 'nonce-${nonce}';
  style-src 'self' 'unsafe-inline';
  img-src 'self' data: https:;
  font-src 'self';
  object-src 'none';
  base-uri 'self';
  form-action 'self';
  frame-ancestors 'none';
  upgrade-insecure-requests;
`

Set it on every response. Test it does not break your app. Tighten further from there.

2. Rate limiting on auth routes

Use Upstash Redis (free tier is generous):

import { Ratelimit } from '@upstash/ratelimit'
import { Redis } from '@upstash/redis'

const ratelimit = new Ratelimit({
  redis: Redis.fromEnv(),
  limiter: Ratelimit.slidingWindow(5, '60 s'),
})

const { success } = await ratelimit.limit(ip)
if (!success) return new Response('Too Many Requests', { status: 429 })

5 attempts per minute per IP on /api/auth/login kills 99% of credential stuffing.

3. DMARC record

Add a DNS TXT record at _dmarc.yourdomain.com:

v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@yourdomain.com; pct=100

Start with p=none if you are nervous, watch the reports for a week, then move to quarantine. This blocks email impersonation cold.

4. DNSSEC

This one depends on your registrar. Cloudflare and Namecheap both have a one-click toggle for it. Most developers do not know it exists. Turn it on.

What I learned building this

Three things, in case you are thinking about building something similar.

Indie devs do not buy "security tools." They buy "did I ship something stupid" anxiety relief. When I positioned UNPWNED as an enterprise-grade vulnerability scanner, conversion was 0.5%. When I positioned it as "scan your domain in 2 minutes before you launch," conversion went up 8x. The product did not change. The job-to-be-done framing changed.

AI fix prompts beat security reports for this audience. Every finding in UNPWNED ships with a copy-paste prompt that the user pastes into Cursor or Claude. The fix happens in their existing workflow. No context switching. The "you have a CSP problem" report is a chore. The "paste this into your AI editor and ship" prompt is a victory lap.

The data itself is the marketing. You are reading this post because the title had a number in it. I would not have hooked you with "I built a security scanner." I hooked you with "81.6% of websites have no rate limiting." Build the thing that gives you proprietary data, then publish the data.

Try it on your own site

If you read this far and you have a side project online, run a scan. It takes 2 minutes, no signup needed, no credit card.

unpwned.io/check takes a domain and gives you a security grade plus the actual list of what is broken.

Full live data on these statistics, including the methodology and a 30-day attack telemetry feed: unpwned.io/data.

If you find something on a real production site that scares you, post it in the comments. I will look at it.

Stay unpwned.

Methodology: figures are deduplicated by domain (latest scan per distinct domain). DNS-based percentages (DNSSEC, DMARC, SPF, DKIM) are based on full data coverage. HTTP-dependent percentages (rate limiting, SSL grading) exclude scans where the target was blocked by Cloudflare or WAF and the scanner could not measure conclusively. Sample: 596 distinct domains, 1,317 total scans, 10,577 findings logged between March 2 and April 30, 2026.