← siteglass blog

We scanned 9,261 freshly-launched sites. Here's what security looks like when nobody's watching.

Over the past few months we ran an automated audit against 9,261 distinct websites, most of them announced on Show HN or freshly pushed to GitHub. New projects. Real launches. 10,858 completed scans, about 101,000 individual findings.

We did not pick these sites because we suspected anything. We picked them because they were new. That turns out to matter, because a newly launched site is a snapshot of what a developer ships when they think they're done.

Here is what we found, and — because a lot of you are excellent engineers who have simply never had to care about this stuff — what each of these things actually means.

No site is named here, and none will be. These are population rates, not addresses.

The short version

That last row is the one to look at twice.

The four missing headers, explained

These four show up on most sites, and all four are one line of config. They are missing not because they're hard but because nothing warns you.

Content-Security-Policy (66% missing). A CSP tells the browser which sources of script it is allowed to run. Without one, if an attacker gets any string of their choosing onto your page — a username, a comment, a URL parameter you echo back — the browser will happily execute it as code. CSP is the difference between "someone put ugly text on my page" and "someone is running JavaScript in every visitor's session." It is the single highest-leverage header on this list.

HSTS (37% missing). You serve HTTPS. Good. But the first time someone types your domain without the https://, their browser makes a plaintext request before your redirect can fire, and anyone on that network can intercept it. HSTS tells the browser "never speak to me in plaintext again," and it remembers. One header, and that whole class of attack disappears after the first visit.

SPF and DMARC (55% and 62% missing). These are DNS records that say who is allowed to send email claiming to be from your domain. Without them, anyone can. Your users get invoices, password resets and support replies that appear to come from you, and nothing in the mail system objects. Developers skip these because they think "I don't send email." But you don't have to send email to be impersonated — the absence of the record is what grants permission. If you own a domain and it has no SPF record, you have effectively left your letterhead on a table in a public square.

The 1.9%

174 sites were serving credentials inside their own client-side JavaScript, where anyone can read them with View Source.

The breakdown is the interesting part:

• 108 exposed a Supabase project
• 52 exposed a JWT or anon key
• 44 exposed a Google API key

That distribution is not random. It is the shape of the modern build-it-fast stack: a frontend framework, a hosted database, and no server in between. When there's no backend, the client has to hold the key, so every tutorial shows you putting it in the client — and it is genuinely fine, right up until it isn't.

Here's the nuance, because it matters and it's where people get burned. A Supabase anon key is designed to be public. It's not a secret. What makes it dangerous is that it's only as strong as the Row Level Security policies behind it. Ship the key with RLS unconfigured, or configured for "get it working," and that public key is a public database. The key being visible is not the bug. The key being visible and load-bearing is the bug.

Same story for a Google API key: harmless if it's restricted by referrer and scope, an open tab at your expense if it isn't.

So the honest reading of 1.9% is not "174 sites are compromised." It is "174 sites have made their security entirely dependent on a configuration most people never check, and some fraction of them have it wrong."

We also found a very small number of sites — under a dozen — where something genuinely unambiguous was exposed. Not keys designed to be public. The kind of file that should never be reachable. We're not describing those further, and we're not naming them.

What we expected to find and didn't

Slowness. The story is that AI-built apps are bloated. Median page load across every page we measured was 939ms, p90 was 2.3 seconds, and only 1% took longer than five seconds. Whatever is wrong with these sites, it isn't speed. Modern hosting is simply very good now.

Accessibility as a differentiator. 77% of sites had at least one high-severity accessibility finding, 60% failed color contrast alone. But that's the rate for the entire web. It's a real problem and it isn't a new one, so it tells you nothing about how the site was built.

The actual conclusion

The interesting failure is not that these sites are broken. Mostly they work, and they're fast.

It's that the defaults are silent. Nothing in a modern deploy pipeline tells you that you have no CSP. Nothing warns you that your domain can be impersonated in email. Nothing flags that the key you pasted from the tutorial is doing more work than the tutorial assumed. You ship, the site loads, it looks right, and every one of these findings sits there invisibly — because the failure mode of all of them is nothing appearing to be wrong.

That's the pattern across all 9,261. Not carelessness. Absence of feedback.

If you want to fix your own in about ten minutes: add a CSP, add HSTS, add an SPF record even if you send no mail, add a DMARC record set to p=none so you at least get reports, and go and read your Row Level Security policies as if you were an attacker holding your anon key — because someone is.

Scans were read-only: fetching pages the way a browser does, reading response headers, and looking at publicly served JavaScript. No site was tested for exploitability and nothing was accessed that a normal visitor could not reach. Findings are aggregated; no individual site is identified.