I checked 50 product launches in 48 hours — 43 shipped with no Content-Security-Policy

Two weeks ago I checked 10 fresh launches: 7 had no Content-Security-Policy. Last week, 8 out of 8.

This week I stopped sampling and just checked everything: 50 products launched in the last few days — "I built this" posts here on dev.to plus new launches on Uneed. Same passive method as always: public HTTP response headers and homepage HTML only. No probing, no auth, nothing a stranger's browser doesn't already see on first load.

Not naming anyone. The aggregate is the story.

The header table, at scale

Only 4 of 50 shipped all six. Those four exist, and they prove it's doable — none of them are big teams.

The CSP number has stopped surprising me (86% this week, 70-100% in earlier batches) and started worrying me. This isn't a obscure hardening step anymore — every major host documents it, every scanner flags it, and it's still the single most-skipped line in launch week.

The finding I didn't expect

One launch this week was running its auth provider's development instance in production — the login handshake was redirecting to the provider's dev domain, which is rate-limited and explicitly not meant for real users. It worked in the maker's testing because dev instances are forgiving. It will break for real users at the worst possible moment: right after launch, when traffic finally shows up.

No test caught it, because "log in once on my machine" passes either way. This is the same shape as every finding in these roundups: nothing fails at deploy time, so nothing gets fixed.

The quiet SEO tax

Better hygiene on the basics — 42 of 50 had exactly one <h1> — but the meta description problem is endemic:

• 17 of 50 run past ~160 characters, so they truncate mid-sentence in search results (the worst I measured: 388 characters — Google shows less than half of it)
• 4 of 50 have no meta description at all, handing the snippet to whatever Google decides to scrape
• 8 of 50 don't serve a readable /robots.txt (a plain 404, or a redirect into an auth handshake) and 11 of 50 have nothing at /sitemap.xml

None of these break the site. All of them cost clicks, every day, silently.

Speed, honestly

Median full page load across the 50: 760ms. That's fine. The tail is not: the slowest 10% start at ~1.6 seconds, and the worst took 3 seconds with over half a second of server think time before a single byte moved. First visits are the visits that decide whether a launch converts — and the first visit pays the full DNS+TLS+TTFB cost every time.

What actually moves the needle

Same conclusion as the last two roundups, now with 5x the data: these aren't skill problems or budget problems. The four all-green sites aren't smarter — they just ran the check before the traffic instead of after.

And the fixes keep being fast when someone points at them. This week: within three hours of a comment on his launch post, one maker had HSTS live and all 15 of his homepage images carrying proper alt attributes — confirmed by re-scan the same day (scans on file). He didn't need a sprint; he needed the list. The gap was never the fix. It's knowing what to fix, in what order, on your specific stack.

Run the check before the traffic, not after.

If you shipped recently and want the full picture on your own site: I run a **Launch-Ready Quick Scan* — passive headers/TLS/HTML checks plus a human-written readout of what to fix first, delivered within 24h. It's $29 for the launch period (normally $49), written so you can hand it straight to whoever owns your deploy config. Grab one here.*