DEV Community: Amit Feldman

Your client handoff checklist is missing the 10-minute security pass

Amit Feldman — Sun, 06 Sep 2026 14:03:29 +0000

If you ship websites for clients, here's a scenario worth five minutes of your time.

It's three weeks after handoff. The client's developer brother-in-law, or their new marketing hire, or — worse — a prospect of theirs, loads the site and runs one of the free header scanners. The result comes back red across the board. Nobody remembers the beautiful Lighthouse score you sent at delivery. The question the client asks is: "Was this site actually finished when we paid for it?"

Nothing is broken. Nothing got hacked. But the story is now "the agency shipped it incomplete," and you're doing unpaid reputation repair on a project that closed a month ago.

I've been running passive launch-readiness scans on newly shipped sites all summer — public response headers and homepage HTML only, the exact thing any scanner or security-conscious prospect sees on first load. The pattern is remarkably consistent, and it applies to client work just as much as indie launches.

The numbers

From a 100-site scan roundup I published in August:

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	Clickjacking — pages iframed anywhere
Referrer-Policy	63/100	Full URLs leak to every third-party request
X-Content-Type-Options	57/100	MIME-sniffing exposure
HSTS	37/100	First-visit downgrade still possible

20 of 100 shipped with all six missing. Only 13 were fully clean.

And it's not just indie makers. This week I checked the homepages of ten boutique web agencies — shops that sell exactly this kind of diligence. Seven of the ten send zero of the six baseline headers on their own sites. I'm not naming anyone; the point is that "the professionals handle this" is not a safe assumption. It's nobody's job, so it's no one's job.

Why your handoff process doesn't catch it

Your delivery checklist almost certainly covers: Lighthouse scores, responsive breakpoints, forms, analytics, SEO meta, SSL certificate installed. All client-visible, all demonstrable in a meeting.

Response headers are invisible in every one of those. Lighthouse doesn't score them. The browser renders fine without them. No test fails, no deploy breaks, no client complains — until the day someone scans the site, and then the conversation is about your competence, not about a config line.

That's the asymmetry that makes this a handoff problem and not a tech problem: the cost lands after you've been paid, on your reputation, and the fix was ten minutes.

The fix is config, not code

All six headers are one-liners at the host or CDN layer. Vercel, Netlify, Cloudflare, nginx — each has a documented snippet, and four of the six can be applied at the edge without even touching the deploy. I published the full copy-paste configs here: The 6 security headers your launch is probably missing — and the one-line fix for each.

Realistic effort for a typical marketing site or small web app:

First site: ~30 minutes (read, apply, verify, tighten the CSP once).
Every site after: ~10 minutes, because it becomes a template.

Add one line to your handoff checklist — "headers scanned, result attached" — and this whole category of awkward conversation disappears.

Turn it into a deliverable, not just a fix

Here's the part most freelancers miss: this is billable, and it's a differentiator.

Clients have been trained by every security vendor's marketing that "secure" is a thing they should worry about and pay for. When you hand over the site with a dated before/after verification report — headers scanned, findings fixed, re-scan clean — you've done three things at once:

Given the client something tangible to justify your invoice against cheaper quotes.
Pre-empted the "was this even finished?" phone call forever.
Created a natural maintenance conversation — headers drift on redeploys and CDN changes, so re-verification is a legitimate recurring line item.

A verification table looks like this (real data, from a site whose owner fixed everything after a flag):

Header	Before	After
HSTS	missing	`max-age=63072000; includeSubDomains; preload`
Content-Security-Policy	missing	`default-src 'self'; base-uri 'self'; object-src 'none'; …`
X-Frame-Options	missing	`DENY`
X-Content-Type-Options	missing	`nosniff`
Referrer-Policy	missing	`strict-origin-when-cross-origin`
Permissions-Policy	missing	`camera=(), microphone=(), geolocation=(), …`

Six fixed, zero regressed, verified by independent re-scan. That table, attached to your handoff doc, is worth more than another page of prose about your process.

If you want it done for you

I run this as a fixed-scope service at Automata HQ:

Launch-Ready Quick Scan — $12: self-serve baseline — headers, TLS basics, mixed content, exposed files. Run it on every client site the week before handoff.
Launch-Ready Audit — $19: full human-reviewed report on one site, prioritized findings with the exact fix per platform, 48h turnaround.
Deep Dive Audit — $99: agency-facing, white-labelable: audit + two retests + a dated "Launch Verified" certificate you can hand the client at go-live. Volume pricing if you're shipping 3+ sites a month.

Or take the checklist above, do it yourself, and charge your client for it — honestly, that's the outcome I'd pick for you. Ten minutes of config, one new line on your handoff doc, and one less way for a finished project to come back as a reputation problem.

Either way: scan the site before the client's brother-in-law does.

What a $19 launch audit actually buys you — a real report, start to finish

Amit Feldman — Mon, 24 Aug 2026 08:03:48 +0000

"Security audit" is one of those phrases that could mean a PDF of platitudes or actual work. Fair enough — I wouldn't buy one sight-unseen either. So here is a real one, using a real launch, with the maker's fixes already public. Everything below is drawn from an actual scan of macless.dev (Aug 16) and its verified re-scan.

Sections 1–3 are what I post free on launch threads — findings-first, no pitch. Sections 4–7 show what the paid Launch-Ready Audit adds on top of the same data.

1. Scope & method (the free scan)

Passive, non-destructive checks only: HTTP response headers, TLS configuration, response timing, on-page SEO basics, robots.txt / sitemap.xml, common exposed paths (.env, .git, backup files).
No login attempts, no fuzzing, no load. Read-only requests you could make with curl.

2. Result summary

Before: 10 passed / 4 warnings / 2 failures.

The base was decent — TLS clean (Let's Encrypt, TLSv1.3), 266 ms response, title, meta description, exactly one H1, robots.txt and sitemap live. The gap: the entire security-header layer missing.

3. Top findings (what the free comment includes)

Finding	Severity	Why it matters
No HSTS	High	First HTTP visit is downgrade-able
No Content-Security-Policy	High	Zero XSS mitigation layer
No X-Frame-Options	Medium	Clickjacking exposure
No X-Content-Type-Options / Referrer-Policy / Permissions-Policy	Low–Med	Hardening gaps that show up on enterprise questionnaires

Plus the one concrete fix: this site is on GitHub Pages, which can't set custom headers — so the fix is Cloudflare (free tier) in front of the domain, headers set at the edge.

4. The paid layer: prioritized fix list, stack-specific

The paid report doesn't stop at "add headers." It orders by real risk and ships the actual config. For this stack:

Fix 1 (highest leverage, ~15 min): Cloudflare → Rules → Transform Rules → Modify Response Header. One rule sets the full static set:

Strict-Transport-Security: max-age=15552000; includeSubDomains
X-Frame-Options: DENY
X-Content-Type-Options: nosniff
Referrer-Policy: strict-origin-when-cross-origin
Permissions-Policy: geolocation=(), microphone=(), camera=()

Fix 2: CSP matched to what the page actually does. This is a static marketing page executing zero JavaScript, so the correct policy is the strict one:

default-src 'self'; script-src 'none'; style-src 'self';
img-src 'self'; font-src 'self'; frame-ancestors 'none';
base-uri 'self'; object-src 'none'; form-action 'self'

Fix 3: HSTS as a toggle under Cloudflare → SSL/TLS → Edge Certificates. No code, no deploy — DNS plus config.

5. The paid layer: what else gets checked

Beyond the passive scan, the $19 audit adds manual review of the things a curl can't see: auth-flow edge cases (session handling, redirect validation, token storage), header drift across routes (your / passing while /app leaks), .env handling and CI/CD secret exposure, and a perf budget pass. Each finding lands in a prioritized list ordered by exploitability, not alphabetically.

6. The paid layer: verified re-scan

Findings → fix → verified re-scan is the whole loop. Macless shipped the fixes within hours; the re-scan (run twice, same day) came back 16 passed / 0 warnings / 0 failures — including a CSP most production sites wouldn't dare run, because it's matched to what the page genuinely loads. That before/after is the deliverable: not a list of problems, a confirmed clean bill.

7. What a report is NOT

Not a pentest. No exploitation, no intrusion — and the report says so, which matters when you show it to a customer.
Not generic. Every snippet above is specific to GitHub-Pages-plus-Cloudflare. A Next.js-on-Vercel report reads completely differently.
Not a one-way door. The $99 Deep Dive adds two retest rounds — ship fixes, get verified, twice.

If you're launching soon and want the fast version first: the $12 Quick Scan is the automated pass plus prioritized findings, 24h turnaround. The $19 Launch-Ready Audit is the full report above, 48h.

And if I already commented on your launch thread: the re-scan is free whether or not you ever buy anything. Ship the fixes and say so — the before/after stories are the best marketing I have.

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

Amit Feldman — Sun, 23 Aug 2026 07:31:54 +0000

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

Check	Missing	Why it matters
Content-Security-Policy	43/50	Nothing mitigating XSS / injected scripts
Permissions-Policy	38/50	Camera/geo/mic unrestricted by default
X-Frame-Options	37/50	Page can be framed anywhere → clickjacking
Referrer-Policy	30/50	Full URLs leak to every third-party request
X-Content-Type-Options	28/50	MIME-sniffing exposure on user content
HSTS	20/50	First-visit downgrade possible

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 $12 for the launch period, written so you can hand it straight to whoever owns your deploy config. Grab one here.*

The 6 security headers your launch is probably missing — and the one-line fix for each

Amit Feldman — Tue, 18 Aug 2026 11:03:58 +0000

I run a passive launch-readiness scan on freshly launched products every day. Public response headers and homepage HTML only — exactly what any visitor's browser sees on first load.

Across the last two scan roundups I published: 15 of 18 launches shipped with no Content-Security-Policy. Most were missing 4+ of the six baseline headers. Not because the makers are careless — because nothing in the deploy pipeline fails when they're absent.

This is the fix-it post. Six headers, what each one actually does, and the copy-paste config for the four platforms most indie launches run on. Twenty minutes, start to green.

The six, in one table

Header	What it stops
`Content-Security-Policy`	Injected scripts (XSS via compromised deps, ad tags, CDN assets)
`Strict-Transport-Security`	First-visit HTTP downgrade / SSL stripping
`X-Frame-Options` (or CSP `frame-ancestors`)	Clickjacking — your site framed inside someone else's
`X-Content-Type-Options: nosniff`	Browsers MIME-sniffing a uploaded file into executable content
`Referrer-Policy`	Full URLs (with tokens/params) leaking to every third-party request
`Permissions-Policy`	Camera/mic/geo being available to any script by default

A sane starter CSP

Don't cargo-cult a huge policy. Start here and tighten:

Content-Security-Policy: default-src 'self'; script-src 'self'; style-src 'self' 'unsafe-inline'; img-src 'self' data:; font-src 'self'; connect-src 'self'; frame-ancestors 'none'; base-uri 'none'; form-action 'self'; object-src 'none'

If you use third-party analytics or fonts, add exactly those origins — no wildcards. frame-ancestors 'none' makes X-Frame-Options redundant, but set both; older browsers only read the header.

Vercel (Next.js)

next.config.js:

async headers() {
  return [{
    source: '/(.*)',
    headers: [
      { key: 'Content-Security-Policy', value: "default-src 'self'; script-src 'self'; style-src 'self' 'unsafe-inline'; img-src 'self' data:; frame-ancestors 'none'; base-uri 'none'; object-src 'none'" },
      { key: 'Strict-Transport-Security', value: 'max-age=31536000; includeSubDomains' },
      { key: 'X-Content-Type-Options', value: 'nosniff' },
      { key: 'Referrer-Policy', value: 'strict-origin-when-cross-origin' },
      { key: 'Permissions-Policy', value: 'camera=(), microphone=(), geolocation=()' },
    ],
  }];
}

One caveat: Next.js inline scripts may need a nonce or 'unsafe-inline' in script-src while you migrate. Ship it in Content-Security-Policy-Report-Only mode for a day first if you're unsure — you'll see violations in the console without breaking anything.

Netlify

_headers file in your publish directory:

/*
  Content-Security-Policy: default-src 'self'; script-src 'self'; style-src 'self' 'unsafe-inline'; img-src 'self' data:; frame-ancestors 'none'; base-uri 'none'; object-src 'none'
  Strict-Transport-Security: max-age=31536000; includeSubDomains
  X-Frame-Options: DENY
  X-Content-Type-Options: nosniff
  Referrer-Policy: strict-origin-when-cross-origin
  Permissions-Policy: camera=(), microphone=(), geolocation=()

Cloudflare (in front of anything)

Dashboard → Rules → Transform Rules → Modify Response Header → set static values for each of the six. Free plan covers it. This is the fix for most of the launches I scan — the app is behind Cloudflare already, and the headers are a five-minute ruleset, not a redeploy.

nginx

Inside your server block:

add_header Content-Security-Policy "default-src 'self'; script-src 'self'; style-src 'self' 'unsafe-inline'; img-src 'self' data:; frame-ancestors 'none'; base-uri 'none'; object-src 'none'" always;
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
add_header X-Frame-Options "DENY" always;
add_header X-Content-Type-Options "nosniff" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
add_header Permissions-Policy "camera=(), microphone=(), geolocation=()" always;

The always matters — without it nginx drops the headers on error responses, which is exactly when you want them.

Two warnings from real launches

HSTS includeSubDomains: only add it if every subdomain you own is HTTPS-ready. One maker locked himself out of a staging subdomain this way.
Test after deploying. curl -sI https://yoursite.com — you want to see all six lines. I've watched makers "fix" headers that never shipped because the CDN in front stripped them.

Why I care

Last week I flagged a missing CSP in a launch's comment thread. By evening the maker had all six deployed — a few hours from "never thought about it" to a fully green re-scan. That's the norm, not the exception: these are config lines, not engineering projects.

If you'd rather have someone run the check and hand you the exact fix list: I do a Launch-Ready Quick Scan — passive headers/TLS/HTML checks plus a written readout of what to fix first, delivered within 24h. It's $12 during launch period. Grab one here.

But honestly, the configs above are the whole job for most sites. Steal them.

All six security headers fixed in a day — the Macless before/after

Amit Feldman — Sun, 16 Aug 2026 15:04:11 +0000

Earlier today I left a findings-first comment on a launch writeup here: a passive scan of the product's site, the top findings with the concrete fix, and an offer of a free re-scan once deployed. No pitch — the scan is the conversation.

The maker read it, put Cloudflare in front of his GitHub Pages site, and closed every single finding within hours. This is the before/after.

The launch

Macless by @maclessdev — a GitHub-Actions pipeline, signing scripts, and notes for building and submitting an iOS app to the App Store without owning a Mac. The marketing page lives at macless.dev, hosted on GitHub Pages.

Before (scan, Aug 16): 10 passed / 4 warnings / 2 failures

The base was decent: TLS clean (Let's Encrypt, TLSv1.3), fast response (266 ms), title, meta description, exactly one H1, robots.txt and sitemap.xml live.

The gap was the entire security-header layer — all six missing:

No HSTS — every first visit over HTTP was downgrade-able
No Content-Security-Policy — no XSS mitigation layer at all
No X-Frame-Options — clickjacking exposure
No X-Content-Type-Options, Referrer-Policy, Permissions-Policy

The frustrating part: none of this is application work. GitHub Pages doesn't let you set custom headers, full stop — so the fix isn't a code change, it's an architecture tweak.

The fix: Cloudflare in front, two Transform Rules

He put Cloudflare in front of the Pages site (free tier) and set the headers at the edge with Transform Rules — no deploy, no code, DNS plus config.

After (re-scan, same day — verified twice): 16 passed / 0 warnings / 0 failures

HSTS: max-age=15552000 (180 days)
CSP: default-src 'self'; script-src 'none'; style-src 'self'; img-src 'self'; font-src 'self'; frame-ancestors 'none'; base-uri 'self'; object-src 'none'; form-action 'self'
X-Frame-Options: DENY
X-Content-Type-Options: nosniff
Referrer-Policy: strict-origin-when-cross-origin
Permissions-Policy: geolocation, microphone, camera all locked down

That CSP deserves a second look. script-src 'none' is bolder than most production sites dare to run — it says this page executes zero JavaScript, which for a static marketing page is exactly true and exactly right. frame-ancestors 'none' plus XFO DENY is belt-and-suspenders clickjacking defense. This isn't a header set copied from a blog post; it's a header set matched to what the page actually does.

Three takeaways for anyone launching on GitHub Pages

1. Pages can't set headers — put a proxy in front. GitHub Pages serves your files and nothing else. If your launch page lives there, the security-header layer doesn't exist until you add Cloudflare (or any CDN that can mutate response headers) in front of it.

2. The fix is a Transform Rule, not a sprint. Cloudflare → Rules → Transform Rules → Modify Response Header. One rule can set every static header. Total elapsed work: minutes. The entire "after" column above required zero commits.

3. Match CSP to reality, then tighten. A static page can run script-src 'none'. An app shell can't. Start from what the page genuinely loads, enforce that, and resist the urge to cargo-cult a permissive policy you saw elsewhere.

Why I'm telling this story

Because this is the loop that works: findings → fix → verified re-scan. @maclessdev didn't pay anyone for this — the first scan and the re-scan were free, and his launch page now passes checks that show up verbatim in enterprise security questionnaires.

I run these scans findings-first on launch posts here regardless of whether anyone buys anything. If you want the full deep pass — auth-flow edge cases, header drift across routes, perf budget, prioritized fix list with stack-specific snippets — that's the Launch-Ready Audit ($19, 48h turnaround): https://afeldman2.gumroad.com/l/zxpluh?utm_source=devto&utm_medium=article&utm_campaign=casestudy-macless
The Deep Dive ($99) adds a written remediation plan + re-scan verification: https://afeldman2.gumroad.com/l/wmdfxb?utm_source=devto&utm_medium=article&utm_campaign=casestudy-macless-deepdive

And if I commented on your launch and you've shipped the fixes, say so in the thread. The re-scan is free, and if the before/after is this clean, I'll write about yours next.

Postscript (September 2026): the layer a header scan can't see

After this article went live, @maclessdev took the same findings-first loop one level deeper — into the CI pipeline itself, which for Macless is the product (signing certificates, App Store Connect keys, GitHub Actions workflows). He ran the pass himself and it turned up two real gaps, both now fixed:

No explicit permissions: block on the workflows. Older repos lean on the default GITHUB_TOKEN scope, which is broader than most people assume. Explicit per-workflow permissions close that.
No .gitignore covering signing material. One stray git add -A and a cert or provisioning profile is in history forever.

Worth stating plainly: the header scan in this article says nothing about any of that. A page can be 16/16 green while a workflow dumps secrets into logs or a token is scoped wider than it needs to be. The checks that caught these: full git history on both repos for committed certs/keys (none, ever), how secrets reach the workflows (environment variables, never shell strings), whether anything logs them (no), and GITHUB_TOKEN scoping. His signing credentials live in encrypted GitHub secrets, and none of the workflows trigger on pull requests — which is the usual way a public repo leaks them.

If your product's crown jewels live in a pipeline and not on the marketing page, that second pass is the one that matters.

5 tools launched this week promising "your data never leaves your browser" — none shipped the header that enforces it

Amit Feldman — Sun, 16 Aug 2026 13:12:38 +0000

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.

I re-scanned the launches I flagged last week — here's who actually shipped the fixes

Amit Feldman — Sun, 16 Aug 2026 09:05:27 +0000

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: DENY
X-Content-Type-Options: nosniff
Referrer-Policy: strict-origin-when-cross-origin
Permissions-Policy locked 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.

I ran a passive security check on 100 freshly launched products — 1 in 5 shipped with zero security headers

Amit Feldman — Fri, 07 Aug 2026 22:05:07 +0000

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 $12 for the launch period, 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.

One maker fixed every security header on his launch in 24 hours — here's the before/after

Amit Feldman — Fri, 07 Aug 2026 09:50:55 +0000

A week ago I started leaving findings-first comments on launch posts here: I run a passive scan of the product's site, post the top findings with the concrete fix, and offer a free re-scan once it's deployed. No pitch in the first touch — the scan is the conversation.

This week one maker did the thing every security person wishes more teams would do: he read the findings, deployed the fixes the same day, and asked for the re-scan. This is the before/after, with his permission-worthy win on full display.

The launch

Loop by @jammyvibez — a collaborative social app where developers share code, fork snippets, and co-write posts live. A Next.js app on Vercel, launched here on August 5th.

Before (scan, Aug 5): 7 passed / 5 warnings / 4 failures

The good news first: HSTS was already strong (max-age=63072000; includeSubDomains; preload), TLS was clean, robots.txt and sitemap.xml were live.

The gaps:

No Content-Security-Policy — the single highest-value header for an app that renders user-generated content
No X-Frame-Options — clickjacking exposure on every page
No X-Content-Type-Options, Referrer-Policy, Permissions-Policy
No <title>, no meta description, no <h1> — the app renders client-side only, so crawlers and link-unfurlers saw an empty shell

That last cluster matters more than people think: every link preview of his launch — in Discord, Slack, X, iMessage — was generating from nothing.

After (re-scan, Aug 6): 15 passed / 1 warning / 0 failures

Under 24 hours later:

CSP live: default-src 'self' with an explicit allowlist for the two third-party origins the app actually loads (Stripe.js and Vercel Analytics)
X-Frame-Options: DENY
X-Content-Type-Options: nosniff
Referrer-Policy: strict-origin-when-cross-origin
Permissions-Policy: camera/microphone scoped to self, geolocation/payment/usb locked down
Title (39 chars), meta description (145 chars), exactly one H1 — the page now renders its metadata server-side

The remaining backlog, which he has in writing: script-src still carries 'unsafe-inline' 'unsafe-eval' (a Next.js hydration constraint you close with nonces when it matters), and TTFB is ~2.1s cold. Neither is a launch blocker. Both are honest items on a real list.

Three takeaways for anyone launching this week

1. Headers are a config file, not a sprint. On Vercel it's a headers() block in next.config.js or entries in vercel.json. On Netlify it's a _headers file. Behind Cloudflare it's one Transform Rule at the edge — no deploy at all. The entire "after" column above was one commit.

2. If your app is client-rendered, your metadata doesn't exist. Crawlers, link unfurlers, and most social scrapers don't execute JavaScript. SSR/SSG your <title>, meta description, and at least one <h1> — or accept that every share of your launch looks blank.

3. Ship CSP in report-only mode first. Content-Security-Policy-Report-Only tells you what would break without breaking it. Let violation reports collect for a few days, allowlist what you actually load, then enforce. Loop's CSP is a good enforced end-state: default-src 'self' plus exactly the origins you use.

Why I'm telling this story

Because this is the loop that works: findings → fix → verified re-scan. @jammyvibez didn't pay anyone for this — the first scan and the re-scan were free, and now his launch passes checks that show up verbatim in enterprise security questionnaires.

I run these scans as Launch-Ready Quick Scans — $12 during launch period, top findings plus the full report — and I keep commenting findings-first on launch posts here regardless. If I commented on yours and you've shipped the fixes, say so in the thread. The re-scan is free, and if the before/after is this clean, I'll write about yours next.

I ran a passive security check on 10 products that launched this week — 7 failed the same one-line fix

Amit Feldman — Wed, 05 Aug 2026 00:05:18 +0000

This week I did something I've been meaning to do for a while: I took 10 products that launched in the last 48 hours — a mix of Product Hunt launches and "I built this" posts on Reddit — and ran a passive launch-readiness check on each one.

Passive means exactly that: public HTTP response headers and homepage HTML only. No probing, no auth attempts, nothing intrusive — the same thing any scanner, prospect, or security-conscious customer sees when they load your site once.

I'm not naming anyone. The point isn't to call out individual makers — it's that the failures were so consistent they form a pattern worth publishing.

The results

7 out of 10 shipped with no Content-Security-Policy header at all.

3 out of 10 were missing Strict-Transport-Security — including one product ranked #1 on Product Hunt the day it launched.

Across the 10 sites, the most common gaps, in order:

Check	Failed	Why it matters
Content-Security-Policy	7/10	Nothing mitigating XSS / injected scripts
Referrer-Policy	6/10	Full URLs leak to every third-party request
Permissions-Policy	6/10	Camera/geo/mic features unrestricted by default
X-Frame-Options	6/10	Site can be framed anywhere → clickjacking
X-Content-Type-Options	6/10	MIME-sniffing exposure on user content
HSTS	3/10	First-visit downgrade possible

Two products were genuinely clean — all six headers present, HSTS with preload. Both were small solo projects, which killed my assumption that "bigger launch = better hygiene."

Why this keeps happening

None of these are code fixes. Every one is a one-line config change at the host or CDN layer — Vercel, Netlify, Cloudflare, nginx, all of them have a documented snippet for it. The failure mode isn't skill, it's that 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."

The SEO side wasn't much better

While I was in the HTML I checked the basics too:

2/10 homepages had no <h1> — your single best keyword slot, empty
Meta descriptions over 200 chars (truncates at ~160 in search results) on half of them
One product had a meta description of 2,701 characters
Missing alt text on the majority of images on 8/10 sites

Again: not skill. Just nobody checked.

What I'd do differently (and did)

I run these checks on every launch now, including my own. My rule is simple: a launch isn't done when the deploy succeeds — it's done when the thing a stranger's browser receives passes a baseline.

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), and the report is 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.

I run a one-person company — here are the 54 prompts I actually reuse

Amit Feldman — Thu, 30 Jul 2026 07:43:36 +0000

Four jobs before lunch

A normal Tuesday for me: 9am I'm a developer, 11am I'm writing landing page copy, 1pm I'm on a discovery call pretending I have a sales process, 3pm an angry email lands and I'm support, 5pm I'm doing the invoicing I've been avoiding since Friday.

The work isn't the expensive part. The switching is. Every hop lands me in front of a blank page in a role I'm mediocre at, and I lose fifteen minutes just working out what good even looks like here. Four hops a day, five days a week. That's most of a working day a week spent staring.

So I did what everyone does now: I asked an AI assistant. "Help me write a cold email." "How should I price this?" And I got exactly what you'd expect — competent, structureless mush. Advice that sounds like a LinkedIn post. The problem wasn't the model. It was that I was asking like someone who didn't know the domain, because in that particular hour, I didn't.

The fix turned out to be boring: stop asking questions, start pasting briefs. A prompt that names a framework, hands over real numbers, sets constraints, and demands a decision rule at the end gets back something I can act on. One that doesn't gets a fortune cookie.

I kept the ones that worked in a file. That file is now 54 prompts across the six jobs I actually do — validation, marketing, sales, ops, finance, support — and I've packaged it up. Here are three of them in full, so you can judge the pattern yourself.

1. The prompt I run before I build anything

When to use this: when you're in love with an idea and need a hostile reviewer to try to kill it before the market does.

Act as a skeptical seed-stage investor who has seen 1,000 pitches and passed on
most of them. Here is my idea:

[DESCRIBE THE IDEA IN 3–5 SENTENCES: who it's for, the problem, the solution,
and how it makes money]

Tear it apart. Specifically:
1. Name the 3 assumptions most likely to be fatally wrong, ranked by
   (likelihood of being wrong) × (damage if wrong).
2. For each, describe the cheapest test (under $100 and under one week) that
   would produce real evidence either way.
3. List who already solves this and why customers might prefer the status quo,
   spreadsheets, or doing nothing.
4. Tell me what evidence would change your mind from "pass" to "curious."

Be direct. Do not soften the critique and do not end with encouragement.

Why it works: the ranking formula stops the model listing ten generic risks and forces a prioritisation. "Under $100 and under one week" converts criticism into this week's to-do list. And the last line matters more than it looks — without it you get a paragraph of encouragement at the end that quietly undoes the whole exercise.

2. The prompt that gets my week back

When to use this: when your week disappears into repetitive admin and you need to know what to automate first.

You are an automation consultant. I'm a solo founder. Here is how I
actually spent my time last week, with hours per task:

[PASTE YOUR TASK LIST, e.g. "answering support emails 4h, invoicing 1h,
scheduling social posts 2h, sales calls 5h, writing content 4h…"]

1. Score every task on two axes: repetitiveness (how rule-based is it)
   and founder-necessity (does it need MY judgment/relationship).
2. Sort all tasks into four quadrants: automate now, delegate, keep
   but time-box, and eliminate.
3. For the top 3 "automate now" candidates, rank by ROI =
   (hours saved per month) ÷ (setup effort), and describe the
   automation for each: trigger, steps, tools ([MY STACK, e.g. "Gmail,
   Stripe, Notion, Zapier/Make"]), and failure mode to watch.
4. Estimate total hours recovered per month and tell me the ONE
   automation to build this week.

Why it works: it runs on your logged hours, not a hypothetical founder's, so the output can't be generic. And step 4 is the whole point — a list of twelve automation ideas is another form of paralysis. I want one.

3. The prompt for the email I shouldn't send at 11pm

When to use this: when a furious email lands and your first-draft reply would make things worse.

You are a customer-success lead who specializes in saving angry
customers. My product: [PRODUCT DESCRIPTION]. Here is the customer's
message:

[PASTE THE ANGRY MESSAGE]

And here is what actually happened / what I can offer: [FACTS + WHAT
YOU CAN DO: refund, fix timeline, workaround, nothing].

Write my reply:
1. First, tell me privately (not for the customer): is this customer
   right? What did we likely get wrong?
2. The reply itself, under 150 words: acknowledge the specific
   failure without legal-speak or "we're sorry you feel that way",
   take ownership of what's genuinely ours, state what I'm doing
   about it with a concrete action and date, and make the remedy
   (if any) without them having to ask again.
3. One sentence I must NOT send (the defensive thing I'm tempted to
   say) and why.
4. A follow-up note to send [N] days later checking the fix landed —
   this is where angry customers become loyal ones.
5. The product/process fix I should make so this exact ticket never
   happens again.

Step 1 and step 3 are why I still use this one. The private read on whether the customer is right usually deflates my defensiveness before I've written a word, and naming the sentence I'm tempted to send is unnervingly accurate about every time.

They're also built to chain: interview notes from the Mom Test script feed the testimonial-to-copy miner, whose output feeds the landing-page hero prompt. Outputs become inputs.

Who this is not for

If you already have a playbook, skip it. Someone who's run sales or done pricing work professionally will find their own frameworks in here with the serial numbers filed off. The pack is for people covering six roles badly, not one role well.
It's prompts, not software. Markdown files plus one print-ready HTML page. Nothing runs, nothing integrates, no accounts. If you want a tool, this isn't one.
The placeholders are work. Every prompt wants real numbers, real quotes, real transcripts. Fill them with vagueness and you get vagueness back — the specificity is doing the heavy lifting, not the wording.
It won't make the decision for you. Several prompts deliberately end in a scorecard or a pass/fail rule. That's a structured argument to react to, not an answer.

Getting it

The Solo Founder's AI Prompt Pack is $19 on Gumroad: https://afeldman2.gumroad.com/l/zdyxz?utm_source=devto&utm_medium=article&utm_campaign=promptpack-launch

54 prompts across six categories, organised Markdown for daily copy-paste plus a single styled HTML file you can print to PDF. Works with any assistant that takes a long prompt — ChatGPT, Claude, Gemini, whatever you already pay for.

And if you just take the three above and never buy anything: genuinely fine. The pattern — name a framework, hand over real data, constrain the output, demand a decision rule — is the part worth stealing.

I built a one-command website auditor because discovery calls were eating my afternoons

Amit Feldman — Thu, 30 Jul 2026 06:08:23 +0000

The discovery-call scramble

If you freelance or run a small agency, you know this moment: a prospect gets on a call and asks, "So what's wrong with our current site?" And you need a credible, concrete answer — not "well, I'd have to dig into it," and not forty minutes of manually opening dev tools, checking headers with curl, running PageSpeed, and eyeballing the source for a meta description.

I got tired of the scramble, so I wrote it down as a checklist, then turned the checklist into a script. It's called siteprobe: one Python file, zero dependencies, standard library only. Point it at a URL and it audits the things clients actually care about — speed, security headers, TLS certificate, and on-page SEO — in about five seconds. Add one flag and it emits a polished HTML report you can attach to a proposal.

python3 siteprobe.py https://example.com

No install, no API keys, no accounts. Python 3.9+ is the only requirement.

What one run actually tells you

Speed, broken down usefully. "Your site is slow" is useless; "your TLS handshake is 800ms because the cert chain is misconfigured" is a fix. siteprobe measures with raw sockets and reports each phase separately:

⏱ Timing
  DNS resolution     12 ms
  TCP connect        34 ms
  TLS handshake      87 ms
  Time to first byte 412 ms
  Total              545 ms

Security headers, with fixes. It checks the six headers on every audit checklist — HSTS, Content-Security-Policy, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy — and every missing one comes back as a PASS/WARN/FAIL finding with copy-paste fix advice, not just "missing."

TLS certificate expiry. Issuer, expiry date, days remaining, negotiated protocol and cipher. It warns under 30 days and fails on expired. If you've ever had a client's site go down because nobody tracked a cert renewal, you know why this is its own line item.

On-page SEO signals. Title tag (with length check), meta description, H1 count, images missing alt attributes, canonical link, viewport meta — plus live checks that /robots.txt and /sitemap.xml actually exist and respond.

The terminal output ends with a summary count, so a run looks like:

✓ 9 passed   ⚠ 3 warnings   ✗ 2 failed

Follows redirects automatically too (up to 10 hops, with the per-hop status codes shown), so python3 siteprobe.py http://github.com tells you the whole story of the redirect chain.

The part that's actually worth paying for

The terminal audit is nice. The deliverable is the point:

python3 siteprobe.py https://client-site.com --html report.html

--html writes a self-contained HTML report — inline CSS, no external assets, no branding to strip out — with styled tables and an overall verdict banner at the top. It's designed to be forwarded to a client or attached to an invoice exactly as it lands on disk. The discovery-call scramble becomes: run one command before the call, attach the report to the proposal after it.

It's also cron/CI-friendly. Exit codes are 0 (all passed), 1 (warnings only), 2 (at least one failure), so a weekly cron job that re-audits your client sites and alerts on exit code 2 is about four lines of crontab. That turns a one-off audit into ongoing monitoring — cert expiry warnings especially.

Honest limitations

It's not a crawler. siteprobe audits the URL you give it (plus robots.txt and sitemap.xml). It doesn't spider the whole site, so per-page SEO issues on page 47 won't show up.
TTFB, not full rendering. The timing is server response, measured with raw sockets. It doesn't run a headless browser, so Core Web Vitals, layout shift, and JS-bundle bloat are out of scope — that's Lighthouse/PageSpeed territory, and the two tools complement each other fine.
Header checks are presence-and-sanity, not policy review. It will tell you CSP is missing; it won't audit whether your existing CSP is well-designed.
Single URL per run. Script it in a loop if you want a batch; there's no built-in site list mode.

Getting it

siteprobe is $12 (pay-what-you-want, $12 minimum) on Gumroad: https://afeldman2.gumroad.com/l/chwsxj?utm_source=devto&utm_medium=article&utm_campaign=siteprobe-launch

You get the single MIT-licensed Python file plus a test suite that spins up a local HTTP server and covers fetching, timing, redirects, header detection, SEO parsing, and HTML report rendering — no network needed to verify it works. If one audit report helps you close one proposal, it's paid for itself several times over.