For the past two weeks I’ve been running passive, read-only security scans on products that launch here on dev.to, and posting the findings publicly with the concrete fix for each. No pitch in the first touch — the scan is the conversation, and I always offer a free re-scan once fixes are deployed.
The part I didn’t expect: how many makers actually shipped the fixes. This is the verification roundup — real before/after numbers from the re-scans.
The pattern across ~100 launches
The headline finding from the broader sweep hasn’t changed: the most common failure is a missing Content-Security-Policy — roughly 7 in 10 launches — followed by missing HSTS. Both are one-line fixes. Almost nobody ships them on day one.
Maker 1: Loop — full remediation in under 24 hours
The fastest turnaround so far. Loop (Next.js on Vercel) launched with 7 passed / 5 warnings / 4 failures: no CSP, no X-Frame-Options, no nosniff, and — because the app renders client-side only — no title, meta description or h1 for crawlers and link-unfurlers.
Under 24 hours later the re-scan read 15 passed / 1 warning / 0 failures. Every failing header closed. I wrote up the full before/after as a case study.
Maker 2: Macless — 5 of 6 headers live within hours
Macless (ship an iOS app without a Mac) launched on GitHub Pages with all six security headers missing. GitHub Pages gives you no header control — so the maker put Cloudflare in front of the domain and used a Transform Rule to set headers at the edge.
My re-scan verified, live:
X-Frame-Options: DENYX-Content-Type-Options: nosniffReferrer-Policy: strict-origin-when-cross-origin-
Permissions-Policylocked down - HSTS on, 180-day max-age
Five of six, in hours. The one still open is the CSP — which is also the one doing the actual XSS work. Same fix path: one more Transform Rule, start with a tight default-src 'self' and loosen only what breaks. If you’re on GitHub Pages, this CDN-front pattern is the way — Pages itself will never give you these headers.
Maker 3: PlaygroundAPI — rescan reads 15 passed / 1 warning / 0 failures
PlaygroundAPI — a free sandboxed mock REST & GraphQL service — came back essentially clean on verification: HSTS at max-age=63072000; includeSubDomains; preload, CSP defined, X-Frame-Options DENY, nosniff, Referrer-Policy and Permissions-Policy all live, TLS 1.3, 267 ms total response. The interesting surface left is the API itself — auth-flow edge cases like token expiry/reuse and session isolation — which is a manual review, not a scanner finding.
Maker 4: the platform-constraint case
One launch on a .streamlit.app subdomain verified their fix but hit a wall: on a platform subdomain you don’t control the edge, so granular CSP and HSTS enforcement isn’t yours to set. Their plan — move to a custom domain with Cloudflare and use Transform Rules — is the correct one, and the same pattern Macless used above. Platform subdomains are fine for demos; if you’re collecting real users, the custom domain is part of the security posture, not just branding.
What I take from this
- Makers fix things fast when the fix is concrete. Every deployed fix above came from a findings comment that included the exact header line or rule to add, not a generic “you should harden your headers.”
- The CDN-front pattern solves the two hardest hosting cases (GitHub Pages, platform subdomains) with the same move: Cloudflare in front, Transform Rules at the edge.
-
CSP is still the last one standing. It’s the highest-value header and the one everyone defers, because a tight CSP can break inline scripts. Ship a report-only policy first (
Content-Security-Policy-Report-Only), watch what fires, then enforce.
Findings on launch posts stay free — the re-scan verification too. If I flagged your launch and you’ve shipped the fixes, reply on your thread and I’ll re-run the check and post the verified numbers, same as above.
I build envcheck, a .env validator and secret-leak scanner for CI — the scans above run on the same engine.
