Last week I posted the results of checking 10 products that had just launched. The pattern was so consistent that I kept going. This is the follow-up: 100 products, all launched within roughly the past week, pulled from Product Hunt, dev.to launch posts, r/SideProject, Peerlist, Microlaunch, Uneed, and a couple of launch directories.
Same rules as before — passive only. Public HTTP response headers and homepage HTML, the exact thing any scanner, prospect, or security-conscious customer sees when your site loads once. No probing, no auth attempts, nothing intrusive.
And same as before: I'm not naming anyone who failed. The point is the pattern, not the callout.
The results
| Check | Missing | What it means |
|---|---|---|
| Content-Security-Policy | 76/100 | Nothing mitigating XSS / injected scripts |
| Permissions-Policy | 78/100 | Camera, mic, geolocation unrestricted by default |
| X-Frame-Options | 67/100 | Pages can be iframed anywhere → clickjacking |
| Referrer-Policy | 63/100 | Full URLs leak to every third-party request |
| X-Content-Type-Options | 57/100 | MIME-sniffing exposure on user content |
| HSTS | 37/100 | First-visit downgrade still possible |
Two numbers that surprised me even after the first batch:
20 out of 100 shipped with all six missing. Not one obscure header — every single baseline protection absent. These weren't broken products; several were polished, well-designed launches with real traction.
Only 13 out of 100 were fully clean. And consistent with the first batch, the clean ones skewed toward small solo projects, not the bigger teams. "More people at launch" does not mean "someone checked."
Why this keeps happening
None of these are code fixes. Every one is a config line at the host or CDN layer — Vercel, Netlify, Cloudflare, nginx, all of them have a documented snippet, and most can apply it at the edge without a deploy. The failure mode isn't skill. Launch week has a hundred things in it and "headers" is item #101. There's no test that fails, no deploy that breaks, no user who complains. The site just quietly tells every visitor's browser: no rules, do whatever.
That's exactly the class of problem that only gets caught by something that checks, every time, automatically — because humans are bad at "every time."
It's fixable fast — I watched it happen
The most common pushback I got last week was "sure, but who has time during launch week?" So here's the counterexample: one maker I flagged went and fixed every missing header within 24 hours — full before/after, verified by re-scan. I wrote it up here: One maker fixed every security header on his launch in 24 hours — here's the before/after. His site went from 5 findings to zero while I slept.
If you're behind Cloudflare, four of the six are a single Transform Rule (Modify Response Header) at the edge — no code change, no deploy. HSTS starts at a short max-age (3600) and steps up once verified. CSP is the one that takes actual care with a SPA, but default-src 'self' plus your API origins is a safe start, and Content-Security-Policy-Report-Only lets you measure before you enforce.
What I'd do differently (and do)
My rule hasn't changed: a launch isn't done when the deploy succeeds — it's done when the thing a stranger's browser receives passes a baseline. 87 out of 100 launches this week hadn't run that check.
If you shipped something recently and want to know where you stand: 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.
And if you're pre-launch: the six headers above are a 20-minute fix tonight. Do it before the traffic, not after.
Top comments (0)