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 $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 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)