A week ago I ran a passive launch-readiness check on 10 freshly launched products and published the pattern: 7 out of 10 shipped with no Content-Security-Policy at all.
This week I did it again — 8 products that launched in the last ~24 hours, all "I built this" posts by solo makers. Same method: public HTTP response headers and homepage HTML only. No probing, no auth, nothing intrusive. Exactly what any scanner, prospect, or security-conscious customer sees on a single page load.
I'm not naming anyone again. The pattern is the point — and this week the pattern got sharper.
The results
8 out of 8 shipped with no Content-Security-Policy.
Not 7 out of 10 this time. All of them.
| Check | Missing | Why it matters |
|---|---|---|
| Content-Security-Policy | 8/8 | Nothing mitigating XSS / injected scripts |
| X-Frame-Options | 7/8 | Site can be framed anywhere → clickjacking |
| Permissions-Policy | 7/8 | Camera/geo/mic unrestricted by default |
| HSTS | 6/8 | First-visit downgrade possible |
| Referrer-Policy | 6/8 | Full URLs leak to every third-party request |
| X-Content-Type-Options | 6/8 | MIME-sniffing exposure on user content |
One product came genuinely close — 5 of 6 headers present, HSTS set for two years, missing only the CSP. That's the closest anyone got.
The part that made me write this
Here's the sharper pattern: 5 of the 8 tools pitch privacy as the product. "Runs in your browser." "Nothing uploaded." "Private by design." Client-side processing is the headline feature — it's in their titles and their hero copy.
And every one of them shipped without the one header that actually enforces that promise.
A CSP is what stops an injected script — a compromised dependency, a malicious ad tag, a poisoned CDN asset — from reading the data your users just trusted never leaves their browser. Without it, "nothing leaves your browser" is a marketing sentence, not an enforced property. One bad script tag away from being false.
None of these makers are careless. Client-side processing is real engineering, and they did it. The gap is that the last mile — telling the browser "only run scripts I explicitly allow" — is a config line nobody wrote, because no test fails and no deploy breaks when it's missing.
The good news: same-day fixes are real
Yesterday I flagged a missing CSP and HSTS in the comments of one maker's launch post. By the evening he'd deployed all six security headers — CSP locked down to script-src 'none', HSTS for 180 days, the full set. His re-scan came back completely green: 16 checks passed, 0 warnings, 0 failures.
Total elapsed time from "never thought about it" to "fully locked down": a few hours, in the middle of launch day.
That's the actual story of these failures. Not skill, not budget — just that launch week has a hundred things in it and headers are item #101. Every fix above is a one-line config at the host or CDN layer: Vercel, Netlify, Cloudflare, nginx, all have a documented snippet.
The SEO side, quickly
Better than last week — 7 of 8 had exactly one <h1> and a real canonical. Remaining nits:
- One homepage had two
<h1>tags — splitting your best keyword slot against itself - One meta description ran 178 characters — truncates mid-sentence in search results (~160 limit)
- One page took 2.9 seconds to respond, with 836ms of server think time — first impression spent staring at a blank tab
What I'd do (and did)
Same rule as last week: a launch isn't done when the deploy succeeds — it's done when the thing a stranger's browser receives passes a baseline. Run the check before the traffic, not after.
If you shipped recently and want the full picture: 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 $12 for the launch period, written so you can hand it straight to whoever owns your deploy config. Grab one here.
And if your product's pitch is "private, runs in your browser": the CSP is the difference between promising it and enforcing it. Twenty minutes tonight.
Top comments (0)