DEV Community: Posting Dude

Chrome Blocked 8 eMudhra CA Keys on Oct 17. A Node Release From Oct 14 Still Trusts Them.

Posting Dude — Mon, 02 Nov 2026 05:28:12 +0000

On Saturday, October 17, at 18:05 UTC, a researcher reported to the Chrome Root Program that the private keys of eight eMudhra intermediate CA certificates could be recovered by anyone. The keys had been generated with weak randomness. With one of them you can sign a certificate for any domain, and clients that still trust that intermediate will accept it.

Chrome blocked the keys 100 minutes later with a CRLSet push. Firefox blocked them the same day. Microsoft followed on the 20th, Apple on the 22nd, and Chrome removed the root above them, emSign ECC Root CA - G3, from its root store on October 27.

That covers browsers. Your backend is not a browser. It calls Stripe, sends webhooks and talks to your email provider through Node, Python or Go, and a lot of those don't read CRLSets. They check against a list of roots that shipped with the runtime or the package.

So I tested it. Same Debian 13 box, with the patched system ca-certificates (20250419+deb13u1) installed. A Node binary released on October 14 still connected to a site signed by a compromised intermediate.

What actually happened, briefly

Eight intermediates under emSign ECC Root CA - G3 had keys that could be recovered straight from the public certificates. eMudhra says it revoked all eight on October 18, that seven were never used in production, and that the one in production had issued zero certificates.
No abuse has been reported. Cloudflare said it found no exploitation on its services, and the test page below says plainly that nobody knows whether non-browser clients were targeted. Browsers also enforce Certificate Transparency, so a forged cert that was never logged fails there anyway.
Most non-browser clients check neither revocation nor CT. For them, the only fix is a trust store that no longer includes those roots.

Dennis Jackson from Mozilla put up a test page with live endpoints signed by the compromised intermediates, plus a list of which packages have shipped fixes. If your client connects and gets the text "That's bad!", it still trusts them. The -noct hosts use leaf certs that were never logged to CT, which is the case an attacker would actually use.

The test

A 13-line script that calls fetch() on the four test hosts:

// check-emudhra.mjs
const hosts = ['dv-g3b', 'dv-g3b-aaa', 'dv-g3b-noct', 'dv-g3b-aaa-noct'];
console.log(`node ${process.version}`);
for (const h of hosts) {
  const url = `https://${h}-emudhra.we-have-a-problem.com/`;
  try {
    const res = await fetch(url, { signal: AbortSignal.timeout(15000) });
    const body = (await res.text()).trim().slice(0, 40);
    console.log(`${h.padEnd(16)} TRUSTED   ${res.status} "${body}"`);
  } catch (e) {
    console.log(`${h.padEnd(16)} rejected  ${e.cause?.code ?? e.message}`);
  }
}

Real output, run this morning:

node v24.22.1
dv-g3b           rejected  CERT_REVOKED
dv-g3b-aaa       rejected  CERT_REVOKED
dv-g3b-noct      rejected  CERT_REVOKED
dv-g3b-aaa-noct  rejected  CERT_REVOKED

node v24.22.0
dv-g3b           TRUSTED   200 "Your client successfully connected to th"
dv-g3b-aaa       rejected  UNABLE_TO_GET_ISSUER_CERT_LOCALLY
dv-g3b-noct      TRUSTED   200 "Your client successfully connected to th"
dv-g3b-aaa-noct  rejected  UNABLE_TO_GET_ISSUER_CERT_LOCALLY

The full body of that 200 is "Your client successfully connected to the site. That's bad!". Node 24.22.0 came out on October 14. Node 24.22.1 is the October 21 security release, which updated the bundled roots to NSS 3.131.1 and added a check that rejects chains containing blocked public keys. That second change is most likely where the CERT_REVOKED comes from.

I ran the same thing in Python with requests, which uses certifi's bundle and not the OS:

certifi 2026.10.23
dv-g3b           rejected  unable to get local issuer certificate
dv-g3b-noct      rejected  unable to get local issuer certificate

certifi 2026.07.22
dv-g3b           TRUSTED   200 'Your client successfully connected to th'
dv-g3b-noct      TRUSTED   200 'Your client successfully connected to th'

(The two -aaa hosts, which use Sectigo cross-signs, were rejected by every client on this box, old or new, so I've left them out here.)

curl on the same machine rejected all four, because it uses the patched system bundle. So the OS was fixed and two of the three clients on it weren't.

Why patching the OS didn't help

Node ships its own copy of the Mozilla root list inside the binary. requests reads certifi's cacert.pem out of your virtualenv. Updating ca-certificates touches neither.

One trap I didn't expect: node --use-system-ca didn't help on the old binary either. It still trusted the bad host. The Node docs say that flag uses the system store "along with" the bundled one, so the old bundled root is still there. --use-openssl-ca, which swaps the bundled store for OpenSSL's system store, did reject all four on the old binary. Upgrading Node is still the real fix. The flag just tells you where the trust is coming from.

Where the old copies are hiding

For a small SaaS or a side project, I'd check these:

Docker images built before October 21. The Node or Python inside is whatever was current at build time. If you pin node:24-slim by digest, it doesn't move until you move it.
Anything on Node 20. It's end-of-life, so it doesn't get the new root list at all. Vercel's advisory says the same thing and tells people to move to 22 or newer.
A pinned certifi in requirements.txt, poetry.lock or uv.lock. Patched from 2026.10.19.
CI runners and self-hosted cron boxes, which tend to drift.
Your Mac. As of the test page's October 28 update, the curl, git and python3 Apple ships still trust the compromised certificates.

The project you haven't touched since summer is the most likely to still have the old list. If that's you, I wrote a list of what to check first when you restart an abandoned side project, and an expired runtime is one of the items on it.

An 18-line check for any machine or image

This prints 1 if emSign ECC Root CA - G3 is still in the system bundle, in the node you're running, or in your certifi:

#!/usr/bin/env bash
# roots-check.sh: 1 = root still trusted (bad), 0 = gone
NODE=${NODE:-node}; PY=${PY:-python3}
needle='emSign ECC Root CA - G3'

count_in_bundle() {
  openssl crl2pkcs7 -nocrl -certfile "$1" | openssl pkcs7 -print_certs -noout \
    | grep '^subject=' | grep -c "$needle"
}

echo "system bundle:          $(count_in_bundle /etc/ssl/certs/ca-certificates.crt)"
echo "node $($NODE -v) bundled: $($NODE -e '
  const { X509Certificate } = require("crypto");
  const hits = require("tls").rootCertificates
    .filter(pem => new X509Certificate(pem).subject.includes(process.argv[1]));
  console.log(hits.length)' "$needle")"
CF=$($PY -c 'import certifi; print(certifi.where())')
echo "certifi $($PY -c 'import certifi; print(certifi.__version__)'):     $(count_in_bundle "$CF")"

Output for the current versions and then the old ones:

system bundle:          0
node v24.22.1 bundled: 0
certifi 2026.10.23:     0

system bundle:          0
node v24.22.0 bundled: 1
certifi 2026.07.22:     1

To check a container, mount the script and run it inside, something like docker run --rm -v "$PWD:/c" your-image bash /c/roots-check.sh. Slim images often lack openssl or python, so just keep the line that applies (for a Node image, the node -e part is all you need).

Is your own site's certificate affected?

This is the other half, and for most indie sites the answer is no. If your cert comes from Let's Encrypt or Google Trust Services, like most small sites, nothing changes for you. It matters if you bought an ECC certificate that chains to emSign ECC Root CA - G3. The University of Michigan, for example, had to replace certificates issued through CERTInext with ECC keys, and its sites behind Cloudflare in Full (strict) mode started returning 526 errors on October 20.

To see which root you're on, look at the issuer line and every row of the chain, not just the expiry date. openssl s_client -connect yourdomain.com:443 -showcerts shows them, or you can paste the domain into a free SSL checker that lists the issuer and the full chain. If "emSign" shows up anywhere in that chain, get a new certificate from a different CA before your visitors start seeing warnings.

The fix list

Node: 22.23.4, 24.22.1 or 26.12.1 or later. Get off Node 20.
certifi 2026.10.19 or later, and update the lockfile too.
Rebuild images with --pull --no-cache so you don't reuse the old layer, then redeploy. Restart long-running processes too. A Node process that's been up since September is still running the old binary with the old roots.
Run check-emudhra.mjs (or curl on the test host) from inside the deployed thing, not from your laptop. Cloudflare's write-up makes the same point: a passing browser test doesn't mean your background worker is fixed.
If something starts failing with certificate errors after you patch, do not "fix" it with NODE_TLS_REJECT_UNAUTHORIZED=0 or verify=False. That turns off the protection you just installed.

This is the second certificate change this month that only shows up when you check what's actually running instead of what the config says. The other one is Let's Encrypt moving to 64-day certificates, where the danger is hardcoded renewal thresholds.

If you pin your base image by digest (which you should for other reasons), what makes you rebuild it? A schedule, Renovate/Dependabot bumping the digest, or only when something breaks?

Your Login Page's ?next= Check Probably Lets /%09/evil.com Through. 10 Strings to Test It With

Posting Dude — Sun, 01 Nov 2026 05:14:28 +0000

Almost every login flow has one: /login?next=/billing. After sign-in you send the user back to wherever they were. And almost every first version of the check looks like this:

const ok = next.startsWith('/') && !next.startsWith('//');

It reads as airtight. It isn't. The problem is that your string check and the browser's URL parser disagree about what the string means.

Why the check fails

The WHATWG URL Standard tells browsers to strip ASCII tabs and newlines from the input before parsing. It also treats \ like / for special schemes such as https. So /\t/evil.com becomes //evil.com by the time it's parsed, which is a protocol-relative URL pointing at another host. /\evil.com gets the same treatment.

The query-string part matters too. When someone sends ?next=/%09/evil.com, searchParams.get('next') hands your code the decoded value, "/\t/evil.com". Your startsWith('/') check passes, and the browser ends up on evil.com.

I ran 10 strings through two checks

Here's a small Node script (Node v24). Check (a) is the naive one above. Check (b) parses the value against your own origin and only accepts it if the origin still matches:

const ORIGIN = 'https://example.app';

function safeNext(next) {
  try {
    const u = new URL(next, ORIGIN);
    return u.origin === ORIGIN ? u.pathname + u.search + u.hash : null;
  } catch {
    return null;
  }
}

The last column shows where the browser actually ends up: new URL(value, origin), plus what happens if the value gets decoded one more time.

Input	Naive check	`new URL` + origin check	Resolves to
`/%09/evil.com` (raw)	ALLOW	`/%09/evil.com`	example.app (but evil.com once decoded)
`//evil.com`	block	block	evil.com
`/\evil.com`	ALLOW	block	evil.com
`\\evil.com`	block	block	evil.com
`/<TAB>/evil.com`	ALLOW	block	evil.com
`https:evil.com`	block	`/evil.com`	example.app/evil.com
`/%2F%2Fevil.com` (raw)	ALLOW	`/%2F%2Fevil.com`	example.app (but evil.com once decoded)
`///evil.com`	block	block	evil.com
`/.evil.com`	ALLOW	`/.evil.com`	example.app/.evil.com (harmless)
`javascript:alert(1)`	block	block	`javascript:` URL

And the real-world case from a query string:

searchParams.get: "/\t/evil.com" -> https://evil.com/

Three takeaways:

Two strings the naive check lets through really leave your site: /\evil.com and a tab-prefixed path. A tab is exactly what ?next=/%09/evil.com becomes after normal query decoding.
The percent-encoded variants are only safe if nothing decodes them again. new URL keeps /%09/evil.com same-origin, but one more decodeURIComponent anywhere in your pipeline (a middleware, a "clean up" helper, a second redirect hop) turns it into evil.com. Validate the final value, then redirect with exactly what you validated.
Redirect to the normalized path, not the raw input. Return u.pathname + u.search + u.hash from the parsed URL, not the original string.

This bug has shipped in real auth tools

oauth2-proxy had exactly this class of bug. The GHSA-j7px-6hwj-hpjg advisory (CVE-2020-11053) says a redirect URL with encoded whitespace characters (%0a, %0b, %09, %0d) could bypass its validation and redirect to any URL.

It's also a classic subject line for unsolicited "bug bounty" emails. If one lands in your inbox, run the 10 strings above against your own check before you reply, and here's how I'd tell a real security report from a beg bounty.

If you're doing OAuth, the stakes are higher. RFC 9700 (OAuth 2.0 Security Best Current Practice) covers open redirectors in section 4.11 and requires exact string matching of redirect URIs in section 2.1, because a loose match plus an open redirect on the client can leak authorization codes.

Framework notes

Next.js: redirect() sends whatever you give it. It doesn't check that the URL is on your origin, so run safeNext() first.
Auth.js: the redirect callback is where you control this. If you customize it, keep the "relative or same-origin only" logic rather than returning url as-is.

The checklist

Parse with new URL(next, yourOrigin) and compare origin. Don't use regex or startsWith.
Fall back to a fixed path (like /dashboard) when the check fails.
Decode once, validate once, and redirect with the value you validated.
Better still, use an allowlist of known paths. The OWASP Unvalidated Redirects and Forwards Cheat Sheet recommends mapping to server-side values where you can.
Add those 10 strings to your test suite. It takes five minutes.

The same idea applies to the other end of a login flow. A ?next= check stops an attacker sending your user somewhere else, and the support inbox has its own version of that, which I wrote up in why "please change my login email" is the riskiest ticket you'll get.

What does your ?next= check look like? I'd honestly like to see the variants people ship.

A Canonical in Your Next.js Root Layout Lands on Every Page. 6 Ways a Canonical Quietly Cancels Itself

Posting Dude — Thu, 29 Oct 2026 05:25:48 +0000

Last week on three of our launch sites (EarlyHunt, MakerHunt and SideHunt) every article under /posts had a canonical tag pointing at the homepage. 14 articles, all quietly telling Google "I'm just a copy of the homepage". Nobody typed that on purpose. The canonical was set once in the Next.js root layout, and every route that didn't override it just inherited it. The pages looked fine, nothing errored, nothing in the logs. We fixed it on Oct 21 and each article now points at itself.

That one got me curious about how many other ways a canonical can quietly cancel itself. So this morning I set up a tiny Next.js 16.4.3 test app, broke it on purpose a few ways, and wrote a small checker. Below is what I found, with the real output.

Quick refresher first. Google's doc on specifying a canonical URL lists three ways to state your preference, in order of strength: redirects (strong), rel="canonical" (strong), sitemap inclusion (weak). The rel="canonical" can go in two places:

a <link rel="canonical"> element in the HTML <head>
a Link: <url>; rel="canonical" HTTP response header

The header is the only option for non-HTML files like PDFs. Google says pick one of the two, because using both "is more error prone" (you end up with one URL in the header and another in the HTML). And it's a hint, not a command. Google can still pick its own canonical.

Here are the six ways I'd check, roughly in the order I'd expect to hit them.

1. A canonical in a shared layout gets inherited by every child page

This is the one that got us. In the App Router, metadata from app/layout.js down to the page.js is merged. The Next.js metadata docs say segments are "shallowly merged" and "duplicate keys are replaced based on their ordering". So if a child page never sets alternates, it keeps the root's.

My test root layout:

// app/layout.js
export const metadata = {
  metadataBase: new URL('https://acme.test'),
  title: 'Acme',
  alternates: { canonical: '/' },
}

And a blog post page that only sets a title:

// app/posts/[slug]/page.js
export async function generateMetadata({ params }) {
  const { slug } = await params
  return { title: `Post ${slug}` }   // no alternates
}

After next build && next start:

== GET /
<link rel="canonical" href="https://acme.test"/>
== GET /posts/hello-world
<link rel="canonical" href="https://acme.test"/>

Same canonical on the post as on the homepage. That's our bug, reproduced in two files.

Fix: keep metadataBase in the root layout (that part is fine and the docs recommend it there), but set the canonical per page:

// app/posts/[slug]/page.js
export async function generateMetadata({ params }) {
  const { slug } = await params
  return {
    title: `Post ${slug}`,
    alternates: { canonical: `/posts/${slug}` },
  }
}

== GET /fixed/hello-world
<link rel="canonical" href="https://acme.test/fixed/hello-world"/>

And put the homepage's canonical: '/' in app/page.js, not the layout. This isn't only a Next.js thing btw. Any framework where a shared layout or theme writes the <head> can do it. Google's old 2013 post on rel=canonical mistakes describes people copying a page template "without thinking to change the target of the rel=canonical".

2. Adding hreflang (or anything under `alternates`) deletes the inherited canonical

This one surprised me more. Because the merge is shallow, alternates is one key. If a page sets alternates.languages and nothing else, the root's alternates.canonical is gone, not merged.

// app/lang/page.js
export const metadata = {
  title: 'Lang',
  alternates: { languages: { 'de-DE': '/de/lang' } },
}

== GET /lang
<link rel="alternate" hrefLang="de-DE" href="https://acme.test/de/lang"/>
canonical count: 0

Zero canonicals. Here it's kind of a lucky accident, since the inherited one was wrong anyway. But flip it around: if your layout had a correct per-route canonical helper and someone adds hreflang to one page, that page silently loses it. Same goes for openGraph, the docs show a child openGraph replacing the whole parent object. If you set alternates anywhere below the root, always set canonical in the same object.

3. Relative paths, and the `./` thing

Google recommends absolute URLs. Relative ones are supported but "can cause problems in the long run (for example, if you unintentionally allow your testing site to be crawled)". The 2013 post has a nice example: writing example.com/cupcake.html without https:// makes it a relative path, so the canonical becomes https://example.com/example.com/cupcake.html.

In Next.js you write relative paths and metadataBase turns them absolute. Per the docs, a relative URL field without metadataBase is a build error, which is a good guardrail. One gotcha: the docs' URL composition table says ./ resolves to the bare metadataBase (https://acme.com). In my test on 16.4.3, canonical: './' on /dotslash resolved to the page's own path:

== GET /dotslash
<link rel="canonical" href="https://acme.test/dotslash"/>

So either the table is about something else or the behaviour changed, I didn't dig further. Either way I wouldn't rely on ./. Write the full path.

4. Two canonical tags

Google's 2013 post is blunt here: "Specify no more than one rel=canonical for a page. When more than one is specified, all rel=canonical links will be ignored." It mentions SEO plugins adding a default one without the site owner knowing.

In a Next.js app, the easy way to get two is having alternates.canonical in metadata and also a hand-written <link rel="canonical"> somewhere in a layout from before you moved to the Metadata API. Or one in HTML and a different one in the Link header from your CDN or host config. Count them, don't just grab the first one. A lot of quick checks do $('link[rel=canonical]').attr('href'), which only reads the first match, so two tags pass.

5. A canonical that points at a 404, a redirect, or a noindex page

The tag can be perfect and the target can still be broken. Google's 2013 checklist: "Double-check that your rel=canonical target exists (it's not an error or soft 404)" and "Verify the rel=canonical target doesn't contain a noindex robots meta tag". A canonical to a URL that redirects is also a mixed signal. You're saying "the real one is over there" and over there says "no, it's somewhere else".

Common ways it happens on small sites: canonical still points at the staging domain, you renamed a route and redirected it but the canonical helper builds the old path, or http vs https / www vs non-www mismatch between the canonical and the URL you actually serve.

You can check this with curl (curl -s -o /dev/null -w "%{http_code}" <canonical-url>, no -L), or if you'd rather paste a URL, a free canonical tag checker I built on Aura++ requests the canonical target and flags anything that isn't a 200. It also reads the Link header and compares against og:url. No signup.

6. The canonical ends up in `<body>`

This is the newest one and I'm honestly not sure how much it matters, so here's what I can show.

Since Next.js 15.2, generateMetadata can stream. From the docs: when it resolves, "the resulting metadata tags are appended to the <body> tag". Next.js says they "have verified that metadata is interpreted correctly by bots that execute JavaScript and inspect the full DOM (e.g. Googlebot)". For "HTML-limited bots" (it detects these by user agent, e.g. facebookexternalhit) metadata stays in the <head>.

Google's canonical doc, on the other hand, says the element "is only accepted if it appears in the <head> section of the HTML".

I tested a dynamic route whose generateMetadata awaits searchParams, with three user agents:

/stream UA=curl/8: canonical byte 5160, </head> byte 590 -> IN BODY
/stream UA=Mozilla/5.0 (compatible; Googlebot/2.1; ...): IN BODY
/stream UA=facebookexternalhit/1.1: canonical byte 544, </head> byte 666 -> IN HEAD

I also loaded it in headless Chrome and checked the rendered DOM. The canonical was still inside <body> after JavaScript ran. Static and SSG pages (like /posts/hello-world above) had it in the head.

I can't see inside Googlebot, so I won't tell you this breaks anything. Next.js says it's fine, Google's doc wording says head. If you don't want to bet on it, the docs give htmlLimitedBots in next.config.js. I set it to /Googlebot/ and re-ran:

htmlLimitedBots=/Googlebot/ UA=Mozilla/5.0 (compatible; Googlebot/2.1; ...) -> IN HEAD

The docs warn this "could lead to longer response times", so it's a trade off. Another option is making the metadata not depend on request data so the route can prerender.

Bonus: og:url that disagrees

og:url isn't one of Google's canonical signals. But if your canonical and og:url disagree, it usually means two pieces of code build "the URL of this page" separately, and one of them is wrong. That's a good place to look for bugs #1 and #3.

PDFs: the Link header

For a PDF there's no <head>, so the header is the only way. In Next.js you can add it in next.config.js:

module.exports = {
  async headers() {
    return [{
      source: '/whitepaper.pdf',
      headers: [{ key: 'Link', value: '<https://acme.test/whitepaper>; rel="canonical"' }],
    }]
  },
}

$ curl -sI localhost:3125/whitepaper.pdf
HTTP/1.1 200 OK
Link: <https://acme.test/whitepaper>; rel="canonical"
Content-Type: application/pdf

Just don't also send a header on HTML pages that already have a tag, that's back to #4.

The quick check

Fastest version is two curls. Run them on a deep page, not the homepage, because the homepage is where a wrong inherited canonical looks right. Here on github.com just to show the output:

curl -s https://github.com/ | grep -io '<link[^>]*rel="canonical"[^>]*>'
curl -sI https://github.com/ | grep -i '^link:'

<link rel="canonical" href="https://github.com" data-turbo-transient>
# (second command printed nothing, so no Link header)

For more than eyeballing, here's the small Node script I used (Node 18+, no dependencies). It reads server HTML only, it doesn't run JavaScript, which is also how I wanted it, so it tells you where the tag is before any script moves things around.

// check-canonical.mjs  usage: node check-canonical.mjs <url> [url...]
// Node 18+, no dependencies. Reads server HTML only (no JavaScript run).
const attr = (tag, name) =>
  (tag.match(new RegExp(`${name}\\s*=\\s*["']([^"']*)["']`, 'i')) || [])[1];

async function check(url) {
  const res = await fetch(url, { redirect: 'follow', headers: { 'user-agent': 'canonical-check/1.0' } });
  const html = await res.text();
  const finalUrl = res.url;
  const headEnd = html.search(/<\/head>/i);
  const problems = [];

  // 1. canonical in the HTML (anywhere, so we can tell head vs body)
  const tags = [...html.matchAll(/<link\b[^>]*>/gi)]
    .filter(m => /rel\s*=\s*["']?canonical["']?/i.test(m[0]))
    .map(m => ({ href: attr(m[0], 'href'), inHead: headEnd === -1 || m.index < headEnd }));

  // 2. canonical in the HTTP Link header
  const linkHdr = res.headers.get('link') || '';
  const hdr = (linkHdr.match(/<([^>]+)>\s*;[^,]*rel="?canonical"?/i) || [])[1];

  // 3. og:url
  const og = [...html.matchAll(/<meta\b[^>]*>/gi)].map(m => m[0])
    .find(t => /property\s*=\s*["']og:url["']/i.test(t));
  const ogUrl = og && attr(og, 'content');

  console.log(`\n${url}`);
  console.log(`  status ${res.status}${finalUrl !== url ? ` (ended at ${finalUrl})` : ''}`);
  console.log(`  html canonical: ${tags.length ? tags.map(t => t.href + (t.inHead ? '' : ' [IN BODY]')).join(' | ') : 'none'}`);
  console.log(`  header canonical: ${hdr || 'none'}`);
  console.log(`  og:url: ${ogUrl || 'none'}`);

  if (!tags.length && !hdr) problems.push('no canonical declared');
  if (tags.length > 1) problems.push(`${tags.length} canonical tags (Google may ignore all of them)`);
  if (tags.some(t => !t.inHead)) problems.push('canonical outside <head>');
  if (hdr && tags.length && new URL(hdr, finalUrl).href !== new URL(tags[0].href, finalUrl).href)
    problems.push('header and html canonical disagree');

  const raw = tags[0]?.href ?? hdr;
  if (raw) {
    if (!/^https?:\/\//i.test(raw)) problems.push(`relative canonical "${raw}"`);
    const target = new URL(raw, finalUrl).href;
    const norm = u => u.replace(/\/$/, '');
    if (norm(target) !== norm(finalUrl)) problems.push(`points elsewhere: ${target}`);
    const t = await fetch(target, { redirect: 'manual', headers: { 'user-agent': 'canonical-check/1.0' } });
    console.log(`  canonical target status: ${t.status}${t.headers.get('location') ? ' -> ' + t.headers.get('location') : ''}`);
    if (t.status !== 200) problems.push(`canonical target returns ${t.status}`);
    if (ogUrl && norm(new URL(ogUrl, finalUrl).href) !== norm(target)) problems.push(`og:url differs: ${ogUrl}`);
  }
  console.log(problems.length ? problems.map(p => '  ! ' + p).join('\n') : '  ok, no findings');
}

for (const u of process.argv.slice(2)) {
  try { await check(u); } catch (e) { console.log(`\n${u}\n  fetch failed: ${e.message}`); }
}

Run on three URLs this morning:

node check-canonical.mjs https://example.com/ https://github.com/ https://www.github.com/

https://example.com/
  status 200
  html canonical: none
  header canonical: none
  og:url: none
  ! no canonical declared

https://github.com/
  status 200
  html canonical: https://github.com
  header canonical: none
  og:url: https://github.com/
  canonical target status: 200
  ok, no findings

https://www.github.com/
  status 200 (ended at https://github.com/)
  html canonical: https://github.com
  header canonical: none
  og:url: https://github.com/
  canonical target status: 200
  ok, no findings

example.com doesn't declare a canonical at all. That's not wrong, Google says you'll "likely do just fine" without one and it'll pick the best version itself. github.com is the textbook version: one absolute self canonical, og:url matches (the trailing slash difference is normalised in the script), target returns 200. And www.github.com redirects to github.com, so the redirect and the canonical agree, which is what you want.

Things the script doesn't do: it won't run JavaScript, it only follows the first Link header canonical, and the og:url and "points elsewhere" checks treat a trailing slash as the same URL. Good enough to catch the six cases above on a deep page.

After you fix it, check what Google actually picked

The tag is your vote, not the result. In Search Console's URL Inspection tool, look at "Google-selected canonical" for one of the affected pages. Google's troubleshooting doc also says re-evaluation takes time, even after a fix it "might hold pages in a duplicate cluster for up to two weeks". So don't panic if it doesn't flip the next day. There's a longer walkthrough on Aura++ about reading URL Inspection when your own name doesn't show up on Google, and a leftover canonical is one of the first things it checks.

For our 14 posts, it's too early to say if the fix changed anything in search, and I'm not going to guess.

The rule I'm keeping

Any time I add or change a layout, template or SEO helper that touches metadata, I open one deep page (a blog post, not the homepage) and check the canonical before calling it done. The homepage is exactly where a wrong inherited canonical looks correct.

Have you ever checked what canonical your blog posts actually point to? And if you're on Next.js 15.2+ with dynamic metadata, did you notice yours landing in <body>, and did you change anything because of it?

One Old CNAME Let Spammers Send Mail as marthastewart.msn.com. Check Your Old Subdomains.

Posting Dude — Wed, 28 Oct 2026 05:28:21 +0000

In February 2024 Guardio Labs published a report on a spam operation they called SubdoMailing. One of their examples was mail sent from marthastewart.msn.com. It passed SPF. It passed DMARC. It was sent from a server in Kyiv that Microsoft had nothing to do with.

The reason was one DNS record. Around 2001, MSN ran a sweepstakes with Martha Stewart. The subdomain marthastewart.msn.com had a CNAME pointing at an outside domain, msnmarthastewartsweeps.com. The promo ended, the outside domain expired, and nobody removed the CNAME. Per Guardio's write-up, nobody registered that domain again for 21 years, until September 2022, when someone bought it through Namecheap. Whoever owns the target of a CNAME controls what the subdomain says, including its SPF record. So they published an SPF record that authorized their own mail servers, and from then on their mail "came from" msn.com. Guardio counted over 8,000 domains abused with this trick or a close cousin of it (more below), including VMware, McAfee, eBay, CBS and Cornell.

I checked today (Oct 28, 2026). The MSN record now points at Microsoft's own edge network, so that one is fixed. And msnmarthastewartsweeps.com is unregistered again. You could buy it right now. It just doesn't matter anymore because nothing points at it.

The reason I'm writing this for indie hackers and not for big companies: we are worse at this than MSN. We buy a domain per idea. We spin up waitlist., docs., status., beta. and old. subdomains on free hosts, then kill the project and delete the Vercel or Heroku app. The DNS record is in a different dashboard, so it stays.

This post is the 15-minute check I'd run on every domain you still own, plus two small scripts. Everything here is read-only. It doesn't attack anything, it just looks up your own DNS.

Three ways a subdomain ends up pointing at someone else

1. A CNAME to a domain you no longer own. This is the MSN case and it's the worst one, because no platform sits in the middle. If the target domain is unregistered, anyone can buy it for the price of a normal domain and gets full control of your subdomain: web content, a valid TLS certificate, and email (SPF/MX on the target domain).

Indie version: blog.mainproduct.com CNAME to myoldblogidea.com, and you let myoldblogidea.com lapse last spring because it was $15 a year for nothing.

2. A CNAME to a deleted resource on a shared host. You point docs.yourapp.com at yourapp-docs.herokuapp.com or an S3 bucket, then delete the app or bucket. Whether someone else can now claim that name depends on the provider. The community list can-i-take-over-xyz on GitHub (EdOverflow/can-i-take-over-xyz) tracks this. When I parsed its table today it had 76 services: 36 marked Vulnerable, 26 Not vulnerable, 14 Edge case. AWS S3, Surge.sh, Ghost and Bitbucket are on the Vulnerable side. GitHub Pages, Heroku, Vercel, Netlify, Shopify and Webflow are Edge case, which I read as "depends on how it was set up, and the provider has added some checks". Fly.io and Firebase are listed as Not vulnerable.

The list says itself it's community-maintained with no guarantee of correctness, so read "Edge case" as "don't rely on it", not "safe".

3. An SPF include (or MX, or NS) that points at something dead. Guardio calls this one SPF-Takeover. Their example was swatch.com, whose SPF record had a:directtoaccess.com in it, an old marketing-service domain that had been abandoned. a: means "any IP that domain's A record points to may send as us". Buy the abandoned domain, point it at your server, and you're an authorized sender for the main domain. No CNAME needed. (Swatch's record no longer has it, I checked.) Same idea with an MX record pointing at a mail host on a dead domain, or a subdomain delegated with NS records to a DNS provider where you deleted the zone (DigitalOcean is on the can-i-take-over-xyz list for exactly that).

What someone actually gets

Microsoft's Azure docs have a decent page on dangling DNS ("Prevent dangling DNS entries and avoid subdomain takeover"), and its risk list applies to any host:

They can get a valid TLS certificate for your subdomain. The padlock means nothing here.
Cookies scoped to your parent domain (Domain=yourapp.com) get sent to every subdomain, including the hijacked one. If your session cookie is set that way, a taken-over old.yourapp.com receives it with every request.
Email that passes SPF/DMARC under your name, like the MSN case. Your customers see your domain.
Phishing pages on a URL your users have reason to trust.

The cookie one is worth 2 minutes on its own. Open devtools on your app, look at the session cookie. If it has no Domain attribute it's host-only and sibling subdomains don't get it. If it shows .yourapp.com, every subdomain you ever created is part of your login security. A __Host- prefix on the cookie name forces host-only (the browser rejects it if a Domain attribute is set), so that's the cheap fix if you don't need cross-subdomain sessions.

Step 1: list every hostname you have

You need two lists, because each one misses things.

Your DNS provider's export. Cloudflare, Namecheap, Route 53 and most others let you export the zone as a text file. That's what actually exists right now.

Certificate transparency logs. Every public TLS cert gets logged, so crt.sh shows names you had certs for, including ones you forgot. This catches the beta2. you made at 1am in 2024:

curl -s "https://crt.sh/?q=%25.yourapp.com&output=json" \
  | jq -r '.[].name_value' | tr 'A-Z' 'a-z' | sed 's/^\*\.//' | sort -u > hosts.txt
echo yourapp.com >> hosts.txt

crt.sh is slow, about 20 seconds for a small domain when I tried it, and sometimes times out. Just run it again. Then paste in every name from the DNS export too and sort -u hosts.txt -o hosts.txt.

Now the part people skip: also make a list of every domain you own or used to own, with its renewal date. Not just the live product. The dead idea domains are exactly the ones that can turn into case 1, if anything still points at them. I'd keep this in the same sheet as a one-evening bill audit for a side project: every domain, renewal date, renewal price, and a keep-or-drop decision. The new rule I'd add to that sheet: a domain can only be dropped after you've searched your other zones for records pointing at it.

Step 2: check every name by hand once

For one name, three commands tell you most of it:

dig +short CNAME docs.yourapp.com          # where does it point?
dig docs.yourapp.com A +noall +comments | grep status   # NOERROR or NXDOMAIN?
curl -sk https://docs.yourapp.com/ | head -c 300        # what does it serve?

If the CNAME is there but the status is NXDOMAIN, the target doesn't exist. That's dangling. Then check whether the target's domain is even registered. RDAP is the newer whois with a proper HTTP API, and rdap.org redirects you to the right registry:

curl -sL -o /dev/null -w '%{http_code}\n' https://rdap.org/domain/msnmarthastewartsweeps.com
# 404

404 means no registration record. Anyone can buy it. For .com that came back from Verisign's RDAP server when I ran it today.

Step 3: check all of them with a script

Doing that by hand for 40 names gets old, so here's the script. It needs only dig and curl.

#!/usr/bin/env bash
# usage: ./check-dangling.sh hosts.txt   (one hostname per line)
# needs: dig, curl. Read-only: DNS lookups, one RDAP lookup, one GET per host.
# Fingerprints from github.com/EdOverflow/can-i-take-over-xyz (a match is a hint, not proof)
FP='There isn.t a GitHub Pages site here|Site not found &middot; GitHub Pages|No such app|NoSuchBucket|DEPLOYMENT_NOT_FOUND|Not Found - Request ID|project not found|Repository not found|Sorry, this shop is currently unavailable'

apex() { echo "$1" | sed 's/\.$//' | awk -F. '{print $(NF-1)"."$NF}'; }  # naive: wrong for .co.uk etc

while read -r host; do
  [ -z "$host" ] && continue
  status=$(dig "$host" A +noall +comments | grep -o 'status: [A-Z]*' | cut -d' ' -f2)
  last=$(dig +short "$host" A | grep '\.$' | tail -n1)   # last CNAME in the chain, if any

  if [ -n "$last" ] && [ "$status" = "NXDOMAIN" ]; then
    code=$(curl -sL -o /dev/null -w '%{http_code}' "https://rdap.org/domain/$(apex "$last")")
    if [ "$code" = "404" ]; then
      echo "CRITICAL  $host -> $last  ($(apex "$last") is not registered, anyone can buy it)"
    else
      echo "DANGLING  $host -> $last  (target does not resolve, check if the provider lets others claim it)"
    fi
    continue
  fi

  if [ "$status" = "NXDOMAIN" ]; then echo "GONE      $host (no record at all, fine)"; continue; fi

  # -k on purpose: a dangling host often has the wrong cert, we only want the error page text
  body=$(curl -sk --max-time 10 "https://$host/" || curl -s --max-time 10 "http://$host/")
  hit=$(echo "$body" | grep -oE "$FP" | head -n1)
  if [ -n "$hit" ]; then
    echo "CHECK     $host -> ${last:-direct}  (page says: \"$hit\")"
  else
    echo "OK        $host -> ${last:-direct}"
  fi
done < "$1"

To test it without pointing it at anyone else's domain, I set up a small fake zone locally. old-promo.lab.test is a CNAME to the real, currently unregistered msnmarthastewartsweeps.com (a replay of the MSN case), status.lab.test is a CNAME to an Azure web app name that doesn't exist, and www.lab.test points at the fixed MSN record. I also fed it the provider default hostnames for apps and buckets that don't exist, which is what a CNAME target looks like after you delete the app. Real output:

OK        www.lab.test -> a-0003.a-msedge.net.
CRITICAL  old-promo.lab.test -> msnmarthastewartsweeps.com.  (msnmarthastewartsweeps.com is not registered, anyone can buy it)
DANGLING  status.lab.test -> zq8x7-none-404.azurewebsites.net.  (target does not resolve, check if the provider lets others claim it)
CHECK     zq8x7-none-404.vercel.app -> direct  (page says: "DEPLOYMENT_NOT_FOUND")
CHECK     zq8x7-none-404.herokuapp.com -> ie02.ingress.herokuapp.com.  (page says: "No such app")
CHECK     zq8x7-none-404-bucket.s3.amazonaws.com -> s3-w.us-east-1.amazonaws.com.  (page says: "NoSuchBucket")
CHECK     zq8x7-none-404.github.io -> direct  (page says: "Site not found &middot; GitHub Pages")
GONE      not-a-real-name.lab.test (no record at all, fine)

How to read it:

CRITICAL: fix today. Delete the record, or buy the domain back yourself if something still needs it.
DANGLING: the CNAME target is gone. For Azure, S3 and the other Vulnerable-list providers, assume someone can claim it. Delete the record.
CHECK: the name resolves to a provider that says "nothing here". Note Heroku and S3 resolve fine even for apps that don't exist, so NXDOMAIN alone won't catch them, that's why the script fetches the page. A CHECK doesn't prove takeover is possible. It means you have a record pointing at nothing, and you should delete it anyway.
GONE / OK: fine.

I also ran it on my own launch sites today: 8 domains, 31 unique hostnames from crt.sh (I didn't add zone exports for this run, so it's the cert-log view only). Nothing came back CRITICAL, DANGLING or CHECK. 18 of the 31 were GONE, old names that had a cert at some point and whose records were already deleted. That's the outcome you want, and it's also a reminder of how many names pile up without you noticing.

Known gaps, so you don't trust it more than it deserves: the apex() function takes the last two labels, so something.co.uk will be checked as co.uk. Fingerprints change when providers redesign their error pages. It doesn't look at A records pointing at raw cloud IPs you released (that's a real risk too, an IP you gave back can be handed to someone else). And a "registered" RDAP answer means somebody owns the domain, not that you do.

Step 4: check your SPF includes

Case 3 is easy to miss because it lives in a TXT record nobody reads. This one lists every include:, redirect=, a: and mx: domain and flags the ones with no registration:

#!/usr/bin/env bash
# usage: ./spf-includes.sh example.com
# lists every include:, redirect=, a: and mx: domain in the SPF record and flags ones nobody owns
dig +short TXT "$1" | grep -i 'v=spf1' | grep -oiE '(include:|redirect=|\ba:|\bmx:)[^ "]+' | sed -E 's/^(include:|redirect=|a:|mx:)//I' |
while read -r inc; do
  apex=$(echo "$inc" | awk -F. '{print $(NF-1)"."$NF}')
  code=$(curl -sL -o /dev/null -w '%{http_code}' "https://rdap.org/domain/$apex")
  if [ "$code" = "404" ]; then echo "UNREGISTERED  $inc  <- anyone who buys $apex can send mail as $1"
  else echo "registered    $inc"; fi
done

On the test zone, where I put the two dead domains from Guardio's report next to a normal Google include:

registered    _spf.google.com
UNREGISTERED  directtoaccess.com  <- anyone who buys directtoaccess.com can send mail as lab.test
UNREGISTERED  msnmarthastewartsweeps.com  <- anyone who buys msnmarthastewartsweeps.com can send mail as lab.test

Both are unregistered again today, years after the report. Domains like this keep coming back on the market, which is why a record you cleaned up is the only real fix. And a "registered" result only tells you that somebody owns the domain, not that you do.

Also look at the "registered" ones and ask if you still use that tool. Every include for a newsletter tool you cancelled is a sender you're still vouching for, and it eats into SPF's 10-lookup limit. I went through that limit in more detail when counting SPF lookups before a launch email. Run the same check on subdomains you send from (mail., news.), not just the root.

Step 5: fix it, in the right order

Delete the DNS record first, then the resource. Microsoft's guidance literally says to put "Remove DNS entry" on the list of required checks when decommissioning. If you delete the Heroku app first and get distracted, you've made a dangling record. Flip the order and the worst case is a broken page for a minute.
Verify your domain with the host where it's supported. GitHub Pages has custom domain verification: you add a TXT record at _github-pages-challenge-USERNAME.yourapp.com and then only your account's repos can use that domain and its immediate subdomains. GitHub's docs say takeovers can happen when you delete the repo, downgrade your plan, or anything else that unlinks the domain while DNS still points there. Azure App Service has the same idea with an asuid. TXT record. Check what your host offers.
No wildcard records (*.yourapp.com) pointing at a shared host. GitHub's docs put it bluntly: wildcards "put you at an immediate risk of domain takeovers, even if you verify the domain", because verifying example.com protects a.example.com but not b.a.example.com.
Before you let a domain lapse, search for it. Grep every zone export you have for the domain name. Any CNAME, MX, NS or SPF include that mentions it gets removed before the renewal date, not after.
If you find a CRITICAL that's been there a while, treat it as maybe-used. Check the subdomain's current content and SPF/MX on the target, and if your session cookie was scoped to the parent domain, rotate sessions.

The 15-minute version

If you only do part of this:

Export your DNS zones and run check-dangling.sh on them plus the crt.sh list.
Run spf-includes.sh on every domain that sends mail.
Look at your session cookie's Domain attribute.
Add "delete the DNS record" as the first line of your project shutdown checklist.

The MSN record sat there for more than two decades and the problem only started when someone bought one cheap domain. Most of us have a few more dead domains than MSN had sweepstakes.

So a narrow question for people running a few products: when you kill a side project, what happens to the domain? Do you keep renewing it forever just in case, or let it go, and if you let it go, did you check that nothing still pointed at it first?

76 of 77 trivy-action Tags Were Repointed in One Night. Some SHA Pins Didn't Help Either.

Posting Dude — Tue, 27 Oct 2026 05:23:11 +0000

On March 19, 2026, someone with stolen credentials force-pushed 76 of the 77 version tags on aquasecurity/trivy-action to point at a credential stealer. All 7 tags on aquasecurity/setup-trivy too. The only clean trivy-action tag was 0.35.0, because it was an immutable release.

If your workflow said uses: aquasecurity/trivy-action@0.34.2, you didn't change a line. Your repo looked exactly the same. The next run just executed different code, for about 12 hours (roughly 17:43 to 05:40 UTC per the advisory), and that code read secrets out of the runner's memory and shipped them off.

The part I keep coming back to is in Aqua's own advisory, under "You are affected if you used":

SHA pinning to a commit prior to 2025-04-09.

So some people who did the "right" thing and pinned trivy-action to a full SHA were still exposed, if their job ran during the ~4 hours setup-trivy was poisoned. Not because the SHA moved. Because the action they pinned called another action by tag.

A lot of small SaaS repos have a CI file that was copied from a README in an afternoon and never opened again. Often a handful of uses: lines, some on @v3 or @main, and a deploy job with a cloud key or an npm token in it. This post is the one-hour version of fixing that.

Three incidents, same shape

These are all public, with advisories you can read:

When	Action	What moved	Window
Mar 14-15, 2025	`tj-actions/changed-files`	multiple version tags repointed to one malicious commit; secrets dumped into build logs	~1 day; GitHub's advisory says it impacted "over 23,000 repositories"
Mar 3-10, 2026	`xygeni/xygeni-action`	the `v5` tag moved to a commit from an unmerged pull request	~6 days
Mar 19-20, 2026	`aquasecurity/trivy-action` + `setup-trivy`	76 of 77 tags, all 7 tags	~12 h and ~4 h

In none of these did the victim's repository change. That's the whole problem with a tag. @v5 is not a version, it's a pointer that gets looked up every time the job starts.

The xygeni one is worth a second look. Branch protection worked, the bad PRs were never merged. But the commit still existed in the repo's git objects, and moving a tag to it was enough. Merged or not doesn't matter to a tag.

Three ways a pin fails

People argue "tags vs SHAs" like it's one decision. It's really three separate failure modes:

1. The tag moves. @v4, @v4.2.2, @main. All mutable unless the publisher uses immutable releases. This is tj-actions, xygeni and trivy-action.

2. Your pin isn't transitive. You pin owner/action@<sha>. That action's own action.yml says uses: owner/other-thing@v1. You get whatever v1 is today. This is the trivy-action pre-April-2025 case: until a commit on 2025-04-09 ("Pin aquasecuriy/setup-trivy to hash instead of tag"), trivy-action's action.yaml called aquasecurity/setup-trivy@v0.2.2. It's right there in the repo history. GitHub's own docs say it plainly now: lockfiles cover transitive dependencies, "which SHA pinning does not."

3. The SHA is real but it's not from where you think. A full SHA can point at a commit that isn't on any branch or tag of the real repo. In the trivy binary part of the same incident, the attacker swapped an actions/checkout reference to what the advisory calls an "imposter commit". GitHub's docs have a one-liner on this: when you pick a SHA, "verify it is from the action's repository and not a repository fork." It's very easy to copy a SHA from a blog post or a bot PR and never check where it lives.

Here's the order I'd fix things in.

Step 1: list what you actually run (10 min)

From the repo root:

grep -rnE '^\s*-?\s*uses:\s*[^ ./$]' .github/workflows \
  | grep -vE '@[0-9a-f]{40}([^0-9a-f]|$)'

This prints every uses: that points outside your repo and isn't pinned to a full 40-character SHA. It skips local ./ actions. It will also show docker:// steps and reusable workflows (jobs.<id>.uses: org/repo/.github/workflows/x.yml@main), which is good, you want to see those too.

On a test workflow it gave me lines like:

.github/workflows/ci.yml:10:      - uses: actions/setup-node@v4
.github/workflows/ci.yml:12:      - uses: docker/setup-buildx-action@v3
.github/workflows/ci.yml:14:      - uses: github/codeql-action/init@v3
.github/workflows/ci.yml:16:        uses: docker://alpine:3.20
.github/workflows/ci.yml:18:    uses: octo-org/shared/.github/workflows/deploy.yml@main

Same idea as grepping your server for hardcoded renewal days before the Let's Encrypt change. You can't fix what you haven't listed.

Write the list down in three groups:

GitHub's own (actions/*, github/*)
Big, well-known publishers (docker, aws, google, cloudflare, vercel...)
Everything else. Small repos, one maintainer, something you found in a Marketplace search at 1am.

Step 2: delete before you pin (10 min)

The cheapest action to secure is the one you remove.

A lot of third-party actions in small repos do something like "post a comment", "get changed files", "set up a tool", "send a Slack message". Some of those are 3 to 10 lines of shell plus gh or curl, which runs with the same token anyway but without someone else's code in the middle. For example, a lot of what people use tj-actions/changed-files for is a git diff --name-only between two commits.

For the ones you keep, look at them once before you trust them. Open the repo: how many maintainers, how old, does it pin its own dependencies, does the action.yml call other actions by tag (that's failure mode 2 again). It's basically the same spelling, age and real-usage check as checking a package an AI coding agent wants to install. A typo in an action name runs someone else's code with your secrets, same as a typo in npm install.

Step 3: pin, and check the pin is honest (15 min)

To get the commit a tag points to right now:

git ls-remote https://github.com/actions/checkout \
  'refs/tags/v4.2.2' 'refs/tags/v4.2.2^{}' | tail -n1 | cut -f1

The ^{} line matters. Some repos use annotated tags, and then the first SHA you see is the tag object, not the commit. tail -n1 takes the peeled commit when it exists. (Before you pin, check that the tag is the release you meant and not already compromised. Pinning a bad commit just makes it permanent.)

Then write it with the version as a comment so humans can read it:

- uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2

Now the check most people skip. This script reads every @<sha> # <tag> line and asks GitHub what that tag points to today:

#!/usr/bin/env bash
# For every "uses: owner/repo@<full sha> # <tag>" line, ask GitHub
# what that tag points to right now and compare it with the pin.
grep -rhoE 'uses:\s*[^ ./$][^ @]*@[0-9a-f]{40}\s*#\s*\S+' .github/workflows |
while read -r _ ref _ tag; do
  sha=${ref##*@}
  repo=$(echo "${ref%@*}" | cut -d/ -f1-2)
  now=$(git ls-remote "https://github.com/$repo" \
        "refs/tags/$tag" "refs/tags/$tag^{}" | tail -n1 | cut -f1)
  if [ "$now" = "$sha" ]; then
    echo "ok     $repo $tag"
  else
    echo "CHECK  $repo $tag pinned=$sha tag-now=${now:-missing}"
  fi
done

On my test file, with one deliberately wrong pin:

ok     actions/checkout v4.2.2
CHECK  actions/checkout v4.2.2 pinned=d632683dd7b4114ad314bca15554477dd762a938 tag-now=11bd71901bbe5b1630ceea73d27597364c9af683
ok     pnpm/action-setup v3.0.0
ok     github/codeql-action v3.29.0

A CHECK means one of two things, and both are worth five minutes: either your SHA was never that tag (copied wrong, or an imposter commit), or the tag moved after you pinned it. The second one is exactly the event you want to hear about. Your pin protected you, but it's also a signal that upstream had a bad day and you should go read their issues.

It only checks the format @sha # tag, it handles owner/repo/subdir actions like github/codeql-action/init, and it needs nothing but git and grep. You could run it weekly in a scheduled job. It does not look inside the actions for failure mode 2, that's what the next step is for.

One tradeoff that's easy to miss: GitHub's docs say Dependabot "will not create alerts for actions pinned to SHA values", alerts are only for actions using semantic versioning. So if you pin by SHA, turn on Dependabot version updates for github-actions so the pins don't rot. Since there's a default cooldown now (Dependabot waits 3 days after a release before proposing it, on github.com), a freshly poisoned release has some time to get caught before a bot PR shows up. That helps with bad new releases. It does nothing for a tag that gets repointed under you, only the pin does.

Step 4: or try the new lockfile (15 min)

On October 14, 2026, GitHub put workflow dependency lockfiles into public preview, including on the Free plan. It's basically package-lock.json for Actions. A CLI extension writes .github/workflows/actions.lock with the commit for every action your workflows use, including the transitive ones, plus the numeric owner and repo IDs. Once a workflow is onboarded, Actions runs the locked commit even if the tag moves, and every dependency of that workflow has to be in the lockfile.

gh extension install github/gh-actions-lock
gh actions-lock                 # scan .github/workflows, write actions.lock
gh actions-lock --verify        # read-only check, good for a CI job

Your workflow keeps readable refs (it may narrow @v4 to @v4.2.2). GitHub's docs now say that for repos with a lockfile, SHA pinning in the workflow file is "no longer necessary". There's also a "Require lockfile" policy at repo/org level, and Dependabot regenerates the lockfile entry in the same PR when it bumps an onboarded workflow.

Things to know before you rely on it, straight from the README and release notes:

It's pre-1.0 and in preview. v0.3.0 (Oct 22) changed behavior enough that some lockfiles that used to pass --verify now fail it.
Reusable workflows called from another repo (jobs.<id>.uses) are not locked by your lockfile.
Container images are not locked. Anything without an @sha256: digest is only a warning.
A lockfile change that moves a floating ref like v4 back to an older commit in its history isn't detected. So review lockfile diffs, or pin exact tags.
Since v0.3.0 it rejects full-SHA pins to fork-only (imposter) commits, every locked commit must be in the history of its recorded tag or branch. That covers failure mode 3.

If you have one repo and a few workflows, I'd honestly try this over hand-pinning. If you're not ready for a preview tool, steps 1 to 3 still get you most of the way.

Step 5: make a stolen run worth less (10 min)

Pinning is about which code runs. This step is about what that code can grab if something slips through anyway. The tj-actions and trivy payloads both went for secrets in the runner's memory. The xygeni one gave the attacker a remote shell on the runner for up to 180 seconds per run, which reaches the same things.

At the top of every workflow:

permissions:
  contents: read

Then give extra scopes only to the job that needs them:

jobs:
  comment:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      pull-requests: write
    # steps: ...

Once you set any permission, every one you didn't list becomes none. permissions: {} turns them all off.

Why bother if new repos default to read-only? Because that default only applies to things created after February 2, 2023. GitHub's changelog was explicit: the change "will not impact any existing enterprises, organizations or repositories." If your repo or org is older than that, go to Settings → Actions → General → Workflow permissions and look. An older repo can still say "Read and write" there.

Two more:

Keep prod secrets out of the PR workflow. Your test job doesn't need the production database URL or the live payment key. Put deploy secrets in an environment with required reviewers. Then only jobs that use that environment can read them, and only after someone clicks approve.
Prefer short-lived cloud creds. If you deploy to AWS/GCP/Azure, OIDC gives the job a token that expires, instead of a long-lived key sitting in repo secrets forever. On GitHub-hosted runners the GITHUB_TOKEN itself already dies with the job, max 6 hours.

Step 6: if you ran a bad version

All three advisories say some version of the same thing: treat every secret the pipeline could read as exposed, and rotate it. Not "probably fine". The trivy payload read the runner's memory, so masked secrets in the logs didn't matter.

The order I'd go in:

Find the runs inside the advisory's window. gh run list --created 2026-03-19..2026-03-20 works, or just scroll the Actions tab.
Rotate whatever those jobs could reach. Cloud keys, deploy keys, package registry tokens, any API key in repo or org secrets.
For trivy specifically, look for a repo named tpcp-docs in your account or org. Per the advisory, the stealer creates it as a fallback upload spot when its normal exfiltration fails.
Check what got published from those runs (releases, packages, images) in case something was tampered.

Rotation is the slow part if you don't know where each key is used. Writing that list down before you need it is worth doing just for this.

The rules I'd actually adopt

At under 50 customers, with one or two people touching CI:

Third-party actions: always locked (lockfile) or SHA-pinned, with the version comment. No exceptions for "it's popular".
GitHub's own actions/*: I'd pin them too. GitHub's "Require actions to be pinned to a full-length commit SHA" policy (added August 2025) treats them the same, and it makes the rule simple enough to enforce.
Fewer actions every quarter, not more.
permissions: contents: read at the top of every workflow, widen per job.
The pin check, weekly.

Total time is about an hour for a typical small repo. The trivy-action window was about twelve hours, starting on a Thursday evening UTC, and the real scan still ran after the stealer, so the job looked normal. Nobody watching their CI casually would have caught it.

I'm curious how other small teams handle this. Are you pinning SHAs by hand, trying the new gh actions-lock preview, or still on @v4? And if you already pin by SHA, have you ever opened the action.yml of what you pinned to see if it calls other actions by tag?

Let's Encrypt Goes to 64-Day Certificates in February. Grep Your Server for 60, 80 and 83 First.

Posting Dude — Mon, 26 Oct 2026 05:18:30 +0000

Let's Encrypt posted a short note on October 7 that most small SaaS founders will scroll past. Starting February 10, 2027, every certificate it issues or renews will be valid for 64 days by default, not 90. Then on February 16, 2028, it drops again to 45 days.

The post also has one line I'd tape to the monitor:

Grep for common hardcoded numbers like 83, 80 or 60 in cron jobs, wrapper scripts and runbooks if you're not sure.

That's the whole risk in one sentence. If your HTTPS renewal was set up two years ago by "past you" and has worked silently since, there's a decent chance a 60 is hiding somewhere in it. On 90-day certs that 60 left you 30 days of slack. On 64-day certs it leaves 4. On 45-day certs it renews two weeks after the cert already died.

This post is the boring checklist I'd run on a tiny SaaS before February. Most of it takes an hour.

The dates, in one place

There are two separate things changing and people mix them up.

The industry rule. The CA/Browser Forum (the group whose rules every public CA follows) passed ballot SC-081 in 2025. Max certificate lifetime for certs issued:

from March 15, 2026: 200 days (it was 398)
from March 15, 2027: 100 days
from March 15, 2029: 47 days

Let's Encrypt's own schedule, which runs ahead of that:

now: 90 days by default
opt-in already: the shortlived profile issues ~6-day certs, and since May 13, 2026 the tlsserver profile issues 45-day ones
since October 14, 2026: the staging environment already issues 64-day certs, for testing
February 10, 2027: default goes to 64 days
around May 11, 2027: the last 90-day Let's Encrypt cert expires
February 16, 2028: default goes to 45 days

Nothing gets revoked. You just get the shorter cert at your next renewal after each date.

If you buy certs instead (from your registrar, or a "1 year SSL" upsell), you're already on the 200-day rule. A public example: as of late October 2026, dev.to itself serves a certificate issued in November 2025 that runs until December 12, 2026. That's 397 days, issued before the cutoff. Its replacement can't be longer than 200 days, and the one after March 2027 can't be longer than 100. If someone on your team installs a bought cert by hand once a year, that turns into at least twice a year now, about four times a year from 2027, and eight or more a year from 2029. Manual stops being a plan.

Why a tiny SaaS should care more than a big one

Big companies have a platform team and a cert inventory. At 30 customers, the cert inventory is "whatever certbot did in 2024."

Two things make it worse now:

Nobody emails you anymore. Let's Encrypt stopped sending expiry reminder emails on June 4, 2025. If you set things up when those emails existed, your safety net was quietly removed. Certbot's own docs still have a line saying the CA will email you, which doesn't help.
Webhooks fail before customers notice. Stripe needs a valid certificate on your webhook endpoint in live mode. If the cert expires, deliveries show a TLS error and Stripe retries for up to three days. After that you're replaying events by hand, and in the meantime renewals, cancellations and failed payments aren't reaching your app. Your marketing site might be on a host that handles certs for you while api.yourapp.com sits on a VPS that doesn't.

Step 1: find out what actually renews your certs

Before grepping anything, figure out which tool is in charge. On a typical small setup it's one of these:

A managed host or proxy (Vercel, Netlify, Cloudflare, Render, Fly, a managed load balancer). They issue and renew for you. Mostly not your problem, but check any custom domains you added by hand.
Caddy. It handles renewal itself and has supported ACME Renewal Information (ARI) since 2.8, so it asks Let's Encrypt when to renew.
Certbot. Usually a systemd timer or a cron entry someone added.
acme.sh. A cron entry under your user.
Something homemade. A script, a Docker container that runs certbot once, a GitHub Action. These are the ones that bite.

On a Linux box, this finds most of them:

systemctl list-timers --all | grep -i -E 'certbot|acme'
sudo grep -rn -i -E 'certbot|acme|renew' /etc/crontab /etc/cron.d /var/spool/cron 2>/dev/null
crontab -l 2>/dev/null | grep -i -E 'certbot|acme|renew'
certbot --version 2>/dev/null
~/.acme.sh/acme.sh --version 2>/dev/null

Write down what you find. Seriously, one line in a notes file: "api box, certbot 2.x, systemd timer, nginx reload hook: no". You'll need it in step 3.

Step 2: grep for the hardcoded numbers

Here's what common renewal rules do on each lifetime. "Slack" is how many days are left on the old cert when renewal first tries.

Renewal rule	90-day cert	64-day cert	45-day cert
Ask the CA via ARI (about 2/3 of lifetime)	~day 60, ~30 left	~day 43, ~21 left	~day 30, ~15 left
Certbot 4.0+ default (1/3 lifetime left)	day 60, 30 left	~day 43, ~21 left	day 30, 15 left
Old certbot default (30 days left)	day 60, 30 left	day 34, 30 left	day 15, 30 left
acme.sh 3.1.2 and older default (59 days after issue)	31 left	5 left	expired 14 days earlier
Hand cron, `--force-renewal` every 60 days	30 left	4 left	expired 15 days earlier
Runbook "renew at 80 / 83 days"	10 / 7 left	expired	expired

The "days left" rules are fine. The "days since issue" rules are the ones that break. That's what Let's Encrypt means by grepping for 60, 80 and 83.

Where to look:

# certbot: per-cert overrides (no output is good)
sudo grep -rn renew_before_expiry /etc/letsencrypt/renewal/

# acme.sh: older versions wrote Le_RenewalDays='60' into every cert's conf
grep -rn Le_RenewalDays ~/.acme.sh/
# (if you never passed --days, a 60 here is just the old default)

# anything homemade that forces renewal on a fixed schedule
sudo grep -rn -E 'force-renew|--days|renew.*(60|80|83)' /etc/cron* /var/spool/cron /etc/systemd/system ~/bin ~/scripts 2>/dev/null

A few things from the changelogs worth knowing:

Certbot 4.0.0 switched its default from a fixed 30 days to "renew when less than 1/3 of the lifetime is left". Certbot 4.1.0 added ARI support, and an early ARI answer wins over a later renew_before_expiry. So a recent certbot with the stock timer is basically fine. An old certbot pinned by your distro is the thing to check.
acme.sh changed its default from 60 days to 30 days and added ARI in 3.1.3 (April 2026). Before that, the default renewal was 60 days after issue, minus a day. If you installed it a while ago and turned off auto-upgrade, acme.sh --upgrade is step one. Then run acme.sh --info -d yourdomain.com and look at Le_NextRenewTimeStr to see when it actually plans to renew, instead of trusting what you remember.
If your "automation" is a cron line with --force-renewal on a fixed calendar, replace it with the plain certbot renew running twice a day. Certbot's docs recommend exactly that and say it's safe to run as often as you like, since it does nothing until a cert is due.

Step 3: renewal isn't deployment

This one gets people even with perfect timing. Certbot renews the file on disk. Nginx keeps serving the old cert from memory until it reloads. If nothing reloads it, the new cert sits there unused and the old one expires right on schedule.

With certbot, add a deploy hook. It only runs after a successful renewal:

sudo tee /etc/letsencrypt/renewal-hooks/deploy/reload-nginx.sh > /dev/null <<'HOOK'
#!/bin/sh
nginx -t && systemctl reload nginx
HOOK
sudo chmod +x /etc/letsencrypt/renewal-hooks/deploy/reload-nginx.sh

With acme.sh it's the --reloadcmd you pass when installing the cert. Their README flags it as IMPORTANT, and they're right.

Other places the new cert never reaches: a Docker image that copied the cert in at build time, a load balancer or CDN where you uploaded a cert by hand, a second server that gets the cert by rsync from the first one. On 90-day certs you might've caught that by accident. On 64-day certs, you get fewer accidents.

To test the renew-plus-hook path without touching real certs:

sudo certbot renew --dry-run --run-deploy-hooks

--dry-run talks to the staging server and doesn't save anything. Deploy hooks don't run during a dry run unless you add --run-deploy-hooks.

Step 4: check the certificate people actually get, from outside

Checking the file on disk tells you what certbot did. It doesn't tell you what browsers and Stripe see. I'd run something like this from a machine that isn't the server, once a day:

#!/usr/bin/env bash
# check-certs.sh: fail if any cert you actually serve expires within DAYS days
DAYS=14
HOSTS="example.com www.example.com api.example.com status.example.com"

fail=0
for h in $HOSTS; do
  cert=$(echo | timeout 10 openssl s_client -connect "$h:443" -servername "$h" 2>/dev/null)
  end=$(echo "$cert" | openssl x509 -noout -enddate 2>/dev/null | cut -d= -f2)
  if [ -z "$end" ]; then
    echo "FAIL $h: couldn't get a certificate"
    fail=1
  elif ! echo "$cert" | openssl x509 -noout -checkend $((DAYS * 86400)) >/dev/null; then
    echo "FAIL $h: expires $end"
    fail=1
  else
    echo "ok   $h: expires $end"
  fi
done
exit $fail

-checkend takes seconds and exits 1 if the cert expires inside that window. -servername matters if more than one site lives on the same IP, otherwise you might be checking the wrong cert.

Pick the alert threshold for the new lifetimes. A lot of us have a "warn at 30 days left" rule from the 90-day era. On a 64-day cert renewed at about 2/3, a healthy cert hits 30 days left around day 34, roughly 9 days before renewal even tries. So the alert fires on every healthy cert, you mute it, and then it can't help you when it matters. I'd use 14 days for 64-day certs and something like 7 to 10 once you're on 45-day ones.

Where the alert goes matters as much as the check. The SideHunt guide on monitoring a side project when you can't watch it all day splits alerts into "interrupt me now" and "tonight is fine". A cert with 14 days left is a tonight one. A cert with 2 days left, or a FAIL on the webhook host, is a now one.

And the check script is itself a cron job that can die quietly. If it stops running, "no alerts" looks exactly like "everything's fine". I wrote about heartbeat checks for the jobs a tiny SaaS runs. Same idea here: ping on success so you hear about it when the check itself stops.

Step 5: find the certs you forgot about

The hostnames list in that script is only as good as your memory. Certificate Transparency logs remember better. Every public cert gets logged, so you can see every name anyone got a cert for on your domain:

curl -s "https://crt.sh/?q=example.com&output=json" | jq -r '.[].name_value' | sort -u

crt.sh is free and kind of slow, and sometimes it just returns a 502. Retry in a minute. What usually turns up: an old staging. subdomain still pointing at a box, status. on some service you set up once, a mail. cert on the mail server, a customer's custom domain. Anything still live goes into HOSTS. Anything dead, delete the DNS record so it stops being a thing.

While you're thinking about expiry dates, the domain itself expires too, and a cert check won't catch that one. The IndieHunt guide on protecting a small SaaS from account lockouts covers registrar lock, auto-renew and the "renewal emails go to the domain that expired" trap.

Step 6: if anything still renews by hand, fix that now

Two cases I'd look for:

Manual DNS challenges. If you ran certbot certonly --manual with DNS and paste a TXT record each time, certbot's docs are clear that those certs won't renew automatically unless you add auth hook scripts. Today Let's Encrypt reuses a successful validation for 30 days. From February 2027 that's 10 days, and on the 45-day schedule in 2028 it's 7 hours. So basically every renewal will need a fresh challenge. Move to a DNS plugin for your DNS provider, or to HTTP validation if the box is reachable on port 80.

Bought certs. If you pay a registrar for a cert because "that's how we did it in 2019", see whether your host can do ACME instead. A lot of paid CAs support ACME too, if you need a paid one for some reason.

Step 7: try the short certs early, on something that doesn't matter

You don't have to wait for February to find out what breaks. Two options:

Staging is already on 64-day certs. Point a throwaway subdomain at a test box, issue with --staging, and watch it over a couple of weeks.
Or opt one low-stakes production name into 45-day certs now. In recent certbot that's --preferred-profile tlsserver, which falls back to the default profile if the profile ever disappears. --required-profile fails instead, which you probably don't want on a real site.

If your setup survives 45-day certs, February is a non-event.

The one-hour version

If you only do part of this:

Find what renews each cert, and write it down.
Grep for 60, 80, 83, --force-renewal and renew_before_expiry. Upgrade old certbot and acme.sh.
Make sure a successful renewal reloads whatever serves the cert.
Add the outside check on every hostname, including the webhook host, alerting at 14 days, with a heartbeat on the check.
Run crt.sh once to find hostnames you forgot.

Most of the time nothing is wrong. But "the cert expired" outages are almost always on a box someone set up once and stopped thinking about, and February takes away a lot of the slack those boxes have been living on.

What renews the certs on your server right now, and do you actually know what day it fires? And if anyone has already moved a real site to the 45-day tlsserver profile, did anything break?

When a Customer Asks to Pay by Invoice Instead of a Card and You Have Under 50 Customers

Posting Dude — Sun, 25 Oct 2026 05:14:06 +0000

Say you sell a $19 per seat tool and most of your 40-ish customers pay monthly by card through Checkout. Then an office manager at a 12-person agency writes:

"We'd like to move the whole team to the annual plan, but our finance team can't put this on a card. Can you send us an invoice, net 30, and we'll pay by bank transfer?"

That's 12 seats x $19 x 12 months, so $2,736 in one go. At under 50 customers that might be your biggest single payment of the year. You want to say yes. But your billing setup assumes a card on file, and "send an invoice and wait" quietly breaks a couple of assumptions in your app, mainly who gets access and when.

This is the version I'd want before replying to that email. What changes in Stripe when a customer pays by invoice, the access trap that comes with it, how bank transfers actually land, and a short policy so the next one takes five minutes.

What "pay by invoice" means in Stripe

Every Stripe subscription has a collection_method. There are only two values:

charge_automatically: the default. Stripe charges the default payment method every period. This is what Checkout subscriptions use.
send_invoice: Stripe creates the invoice and emails it to the customer, with a due date. They pay it themselves, whenever they get to it before (hopefully) the due date.

For send_invoice you also set days_until_due (the "net 30" part). The invoice email links to a hosted invoice page where the customer can pay with whatever payment methods you've enabled for invoices, and download a PDF of the invoice and the receipt. For finance teams the PDF is the whole point, they need something to attach in their accounting system.

One small timing detail from the subscription invoice docs: with charge_automatically Stripe finalizes the renewal invoice right away, with send_invoice it finalizes it about an hour later. So if you have code that reacts to invoice.finalized, don't expect it at the exact second the period renews.

If this agency also wants their VAT number or company address on the invoice, that's its own small project. I wrote up what to set before you send a business customer an invoice with their VAT number, and it's worth doing that first, because a finalized invoice keeps the tax details it was finalized with.

The trap: "active" doesn't mean "paid" anymore

This is the part that matters most, and it's easy to miss.

With card subscriptions, a new subscription whose first payment fails sits in incomplete. Your paywall checks for active (or active and trialing) and everything is fine, because active roughly means "money came in".

With send_invoice, Stripe's API reference says it plainly: subscriptions with collection_method=send_invoice "are automatically activated regardless of the first Invoice status." The subscriptions overview says the same thing, the initial status is active "even if the first invoice is unpaid."

So if your app does this:

const hasAccess = sub.status === "active" || sub.status === "trialing";

then the agency gets full access for 12 seats the minute you create the subscription, before a cent arrives. For net 30, that's 30 days of access on trust, plus however long it takes you to notice the invoice is overdue.

Later on, the status does catch up. When a send_invoice invoice isn't paid by its due date, the subscription moves to past_due. Then, depending on your settings, it can stay past_due, become unpaid or get canceled. More on that below.

For a 12-person agency that asked politely, access on trust is probably fine. The point is to decide it on purpose instead of finding out your paywall decided for you. Three options:

Policy	How it works	Good for
Access on trust	Give access when the subscription is created, cut it when it goes `past_due`	Known companies, renewals of existing customers
Access on payment	Keep the account locked (or on a trial) until the first invoice is `paid`	New companies you've never heard of
Short first term	First invoice net 7, later renewals net 30	Somewhere in between

Update (Oct 26): thanks to @davekurian for catching a bug in the first version of this snippet: it checked latest_invoice, which on a renewal is the new invoice still open inside net 30, so it locked out customers who'd already paid for the year. The version below stores a paid-through date from invoice.paid and checks it plus a grace window.

If you go with "access on payment", don't check the latest invoice at access time. Store a paid-through date when Stripe tells you an invoice was paid, and check against that. Something like this (illustrative, check the field names against your SDK and API version):

// Webhook handler, after verifying the signature.
// invoice.paid also fires when you mark an invoice paid out of band.
if (event.type === "invoice.paid") {
  const inv = event.data.object as Stripe.Invoice;
  // API 2025-03-31 and later; older versions use inv.subscription
  const subId = inv.parent?.subscription_details?.subscription;
  if (subId) {
    const sub = await stripe.subscriptions.retrieve(subId as string);
    // Stripe's docs: confirm the subscription is active before extending access
    if (sub.status === "active") {
      // the service period this invoice paid for (not inv.period_end)
      const ends = inv.lines.data
        .filter((l) => l.parent?.type === "subscription_item_details")
        .map((l) => l.period.end);
      if (ends.length) await savePaidThrough(sub.id, Math.max(...ends)); // only ever move it forward
    }
  }
}

async function hasAccess(sub: Stripe.Subscription) {
  if (sub.collection_method !== "send_invoice") {
    return sub.status === "active" || sub.status === "trialing";
  }
  if (["canceled", "unpaid", "incomplete_expired", "paused"].includes(sub.status)) return false;
  if (await hasManualOverride(sub.customer)) return true;
  const paidThrough = await getPaidThrough(sub.id); // unix seconds, null until an invoice is paid
  if (!paidThrough) return false; // first invoice not paid yet: stays strict
  const graceDays = (sub.days_until_due ?? 30) + 7; // net terms plus a week
  return Date.now() / 1000 < paidThrough + graceDays * 86400;
}

The first invoice stays strict (no paid-through date, no access). A renewal keeps access while the new invoice is open, up to its net terms plus a week. Use the line item's period.end for this, not the invoice's period_end. Stripe's docs point you to the line item period for the service period, and on a renewal invoice period_end is not the end of the year they just paid for. If you have customers who paid before you add this, backfill their paid-through date once from their last paid invoice.

The hasManualOverride bit is for the "they emailed me the remittance PDF and the bank transfer is on its way" case. You'll want a way to say "yes, give them access now" without hacking the database.

How bank transfers actually land

You can let invoice customers pay by card on the hosted invoice page too, but if finance asked for bank transfer, they mean it. Stripe supports this through what it calls the customer balance, and the mechanics are nicer than I expected:

Stripe gives each customer a unique virtual bank account number and puts it on the invoice PDF and the hosted invoice page. Your real bank details are never on the invoice.
The same customer gets the same account details on every invoice, so their finance team can save you as a payee once.
When money arrives, Stripe tries to match it to an invoice automatically. First by the invoice number in the transfer reference, then by exact amount against the oldest open invoice, then a couple of fallback rules.
If it can't match, the money sits in that customer's cash balance and you get a cash_balance.funds_available webhook. You reconcile it by hand.

A few details worth knowing before the first one arrives:

Underpayments. If the customer sends less than the invoice total, the invoice stays open until the full amount is covered. This happens a lot with international wires, where a bank fee gets taken in the middle. There's a setting (Settings > Billing > Invoices, under Adjustments and reconciliation) to automatically write off small differences below a threshold you pick.

Overpayments and leftovers. Extra money goes into the customer's cash balance. If funds sit unreconciled for 75 days, Stripe tries to send them back to the customer's bank. If they're still there at 90 days, Stripe moves them to your Stripe balance.

Currencies and countries. Bank transfers work for EUR, GBP, JPY, MXN and USD, and which ones you can offer depends on where your Stripe account is. In the Dashboard you can only make bank transfer a default payment method for USD and GBP invoices, for other currencies you add it per invoice. International SWIFT wires are listed as US-only, in USD.

EU transfers. Stripe's docs warn that the beneficiary name the customer types should match your business name on Stripe exactly, or the payment can get held for extra screening. Put your registered business name in the reply email so they copy it.

Refunds and reversals. Bank transfer payments mostly can't be pulled back the way card payments can (the docs list USD and CAD as the exceptions). And Stripe says it doesn't support refunds for international wires, you'd handle those yourself.

Stripe's page on accepting bank transfers on invoices has the full matching rules and the API calls. To turn it on for subscription invoices you set payment_settings[payment_method_types] to include customer_balance.

The fee math (why finance teams ask for this)

Using the US list prices on Stripe's pricing pages as I read them in October 2026 (yours depend on your country and any custom pricing, so check):

Card: 2.9% + 30¢. On $2,736 that's about $79.64.
USD bank transfer: 0.5%, capped at $5. On $2,736 that's $5. Stripe's page also lists $15 per wire payment, so a wire rather than an ACH transfer costs more.
Stripe Billing itself (pay as you go) is 0.7% of Billing volume, and it applies whichever way they pay. Roughly $19 here.

So on an annual plan of this size, bank transfer saves you about $75 versus a card. Not life changing, but real. On a $19 monthly invoice for one seat the difference is pennies and the extra admin isn't worth it. That's why I'd only offer invoicing on annual plans or above some team size.

When they pay straight into your bank

Some finance teams will ignore the virtual account and pay your normal business account because "that's who we have on file". Stripe can't see that money. You mark the invoice as paid yourself, in the Dashboard or with paid_out_of_band=true on the pay endpoint, which marks it paid without charging anything.

Two cautions. Do this only after the money is actually in your account, not when they say it's been sent. And the Billing pricing page says the 0.7% covers Billing volume "processed on and off Stripe", so marking it paid outside Stripe doesn't obviously get you out of that fee. I'd check with Stripe on your own plan before assuming.

Moving an existing card customer to invoices

Often it's an existing monthly customer who's upgrading to annual and switching how they pay at the same time. Changing collection_method on a live subscription is allowed, and per the collection method docs only invoices created after the change use the new method. Roughly:

curl https://api.stripe.com/v1/subscriptions/sub_123 \
  -u "sk_live_...:" \
  -d collection_method=send_invoice \
  -d days_until_due=30 \
  -d "payment_settings[payment_method_types][0]=customer_balance" \
  -d "payment_settings[payment_method_types][1]=card"

The monthly to annual switch is a separate change with its own proration and billing date questions, so do one at a time and look at the upcoming invoice before you confirm anything to the customer. Also make sure the customer record has the right billing email. With send_invoice the invoice goes to that email, and if it's the office manager's personal address instead of accounts@ it'll sit in the wrong inbox for 30 days.

One more thing: invoice-paid subscriptions don't support the newer Stripe pause (it requires charge_automatically). If an invoice customer later asks to pause, you'll be looking at a different option.

What happens when they don't pay

Card subscriptions have retries. Invoices don't really, the customer has to act. What Stripe gives you instead:

Reminders. Up to three reminder emails, from 10 days before the due date to 60 days after (Settings > Billing > Subscriptions and emails, "Send reminders if a recurring invoice hasn't been paid").
What happens to the subscription. 30, 60 or 90 days after the invoice is past due you can have Stripe cancel the subscription, mark it unpaid, or leave it past_due. With unpaid, new invoices keep getting created but stay as drafts.

At under 50 customers I wouldn't let a robot handle this one alone. A $2,736 invoice that's 10 days late deserves a short personal email to whoever asked for it, not just a Stripe reminder to accounts@. Usually it's stuck in an approval queue and one nudge fixes it. If you're going to write these emails anyway, I put together a playbook on billing emails that cut support tickets that covers renewal and receipt emails too.

A small invoicing policy

Write it once, paste it into the reply next time:

Who can pay by invoice. Annual plans only, or maybe 5+ seats. Monthly stays on card.
Terms. Net 30 for renewals, net 7 or net 14 for a first invoice.
Access. On trust from day one, or after first payment. Pick one and make your paywall match.
How to pay. Bank transfer to the details on the invoice, invoice number in the reference. Card on the same page works too.
What happens if it's late. A personal email at about 7 days overdue, access paused at about 30, and what that looks like for their team.
Paperwork. Company name, address, tax ID collected before the first invoice is finalized.

Then the reply to the agency writes itself:

"Happy to. I'll set the team up on the annual plan for 12 seats and send an invoice for $2,736 with 30 day terms. It'll come from Stripe with bank transfer details, please put the invoice number in the transfer reference so it matches automatically. Can you send me the company name, billing address and the email the invoice should go to? Your team keeps access while the invoice is open."

And once a company is paying for 12 seats, they'll start asking for roles, shared workspaces and someone other than the office manager who can see the invoices. If your product was built for one person per account, I wrote about adding team accounts to a product built for one user and what to change first.

Quick checklist

[ ] Decide who's allowed to pay by invoice (annual, team size)
[ ] Set collection_method=send_invoice and days_until_due
[ ] Remember send_invoice subscriptions are active before they're paid, and fix the paywall to match your policy
[ ] Turn on bank transfers (customer_balance) and check your currency is supported
[ ] Billing email on the customer is the finance inbox, company details set before finalizing
[ ] Reminders on, plus your own personal email when it's late
[ ] Know what to do with underpayments, overpayments and money that lands in your own bank account
[ ] Decide what Stripe does at 30/60/90 days past due

So, a question for anyone who already sells to teams: when a customer pays by invoice, do you give access the day the invoice goes out, or only once it's paid? And what days_until_due did you end up using for the first invoice?

When a Customer Asks to Pause Their Subscription and You Have Under 50 Customers

Posting Dude — Sat, 24 Oct 2026 05:16:48 +0000

Say you sell a small tool to wedding photographers. You have 40-something paying customers, mostly monthly. In November one of them writes:

"Season's done for me. Can I pause until March instead of cancelling? I don't want to lose my setup."

That's a good email to get. They're not leaving, they just don't want to pay for four months of nothing. But if you've never done a pause before, you open the Stripe Dashboard and find there are now two different buttons with "pause" in the name, and they do very different things. Pick the wrong one and you either keep charging them (well, invoicing them) all winter, or you lock someone out who only wanted a payment break.

This post is the version I'd want before answering that email. What each pause actually does in Stripe, what your app has to check, and a small pause policy you can write once and reuse. With under 50 customers every pause is a person you'll talk to again in March, so it's worth getting right.

Stripe has two kinds of pause now

This changed recently, so older blog posts are out of date. For years the only "pause" was pause_collection. On 2026-09-30 Stripe's changelog added the ability to pause and resume subscriptions on demand (it was in preview earlier this year). So now:

1. Pause payment collection (pause_collection on the subscription)

The subscription stays active.
Invoices still get created every period, Stripe just doesn't collect them.
The customer keeps access, because nothing about the status changed.
Stripe's own docs describe it as a grace period, for when "a customer needs more time to pay or can't pay for one or more billing periods."

2. Pause the subscription (the newer pause endpoint, or "Pause subscription" in the Dashboard)

The status changes to paused.
Stripe stops generating invoices until you resume.
It's meant to stop service too. The docs literally say to make clear that pausing "stops both service delivery and invoice generation."
It needs the subscription to be on flexible billing mode, and a few other things (more on that below).

So the photographer who's away until March wants #2. A customer who says "money is tight this month, can I keep using it and pay later" wants #1. Most of the confusion is just using one for the other.

The easy one: pausing payment collection

You can do this from the Dashboard (open the subscription, the ⋯ menu, Pause payment collection) or with one API call:

curl https://api.stripe.com/v1/subscriptions/sub_123 \
  -u "sk_live_...:" \
  -d "pause_collection[behavior]=mark_uncollectible" \
  -d "pause_collection[resumes_at]=1803859200"  # 2027-03-01 00:00 UTC

resumes_at is optional. Leave it out and collection stays paused until you unset it yourself, which is how you end up with a customer who quietly used the product free for a year because nobody remembered.

The part people skip is behavior. It decides what happens to the invoices Stripe keeps creating while collection is paused:

behavior	what happens to each invoice	use it when
`keep_as_draft`	stays a draft, `auto_advance` off	you're deferring, they'll pay later
`mark_uncollectible`	marked uncollectible (customer balance applied first)	you're forgiving the period
`void`	voided, no record of a charge	you're forgiving and want no trail

Two things in the docs that are easy to miss:

keep_as_draft means they still owe you. When you resume, the drafts don't collect themselves. You have to turn on automatic collection for each one (auto_advance=true), and then they get charged for the paused months too. If you told the customer "no charge while paused", don't pick this one.
Invoices from before the pause keep getting retried unless you void them. So if the customer already had a failed renewal and you pause collection to be nice, Stripe can still retry that old invoice. Look at their open invoices before you click.

Also, while collection is paused Stripe doesn't send upcoming invoice emails or webhooks for those invoices. Quiet is nice, but it also means your own "your plan renews soon" logic, if it hangs off those webhooks, goes silent for that customer.

The real pause: status becomes `paused`

In the Dashboard it's the ⋯ menu, Pause subscription. You choose whether it starts now or on a date, and whether it stays paused "until you resume it" or until a specific date. The date option is the one you want for the photographer: pause now, resume March 1.

What happens when you pause, per Stripe's docs:

status changes to paused
current_period_end gets moved to the moment you paused
no new invoices until resume
you get customer.subscription.paused (plus customer.subscription.updated)

And the money part. By default Stripe credits the unused time, from the pause moment to the end of the period, as a pending invoice item. Stripe's example: $30/month plan, paused on day 15, you get a -$15 pending item. Resume on day 45 and the resumption invoice has the -$15 credit plus a fresh $30 period, so they pay $15 and a new cycle starts. You can change that with bill_for[unused_time_from] (now, item_current_period_start, or none), and invoicing_behavior decides if the credit sits as a pending item (default) or gets invoiced right away.

If you'd rather see the numbers before you commit, Stripe lets you preview a pause invoice, but only if invoicing_behavior is invoice. With the default it returns a 404, which is easy to read as "something's broken", so heads up.

Why the pause button might be greyed out

Stripe lists the cases where you can't pause:

the subscription uses send_invoice instead of charging automatically
it's on classic billing mode (you'd migrate it to flexible first)
it's in a free trial set with trial_end / trial_period_days
status is unpaid, incomplete, incomplete_expired or canceled
it has a subscription schedule attached (you pause through the schedule instead)

On billing mode: per Stripe's docs, API version 2025-09-30.clover and later default new subscriptions to flexible, older versions default to classic, and Dashboard-created ones follow a setting under Settings > Billing > Subscriptions and emails. If you set things up a while ago there's a fair chance your early subscribers are classic. Migration is one way only (flexible can't go back to classic), so read Stripe's compare page before migrating everyone just to get a pause button. For one customer who wants a pause next week, pause_collection plus a note might honestly be fine.

Resuming without a surprise

The resume step has a default that I'd change. The payment_behavior options:

resume_on_payment_attempt (default): the resume call doesn't try to charge. If the charge on that invoice fails later, the subscription goes to past_due and Stripe doesn't retry.
resume_on_payment_success (Stripe calls it recommended): it tries the payment in the request, stays paused until payment works, and retries.

Also, a resume request can return 200 while the subscription is still paused and the invoice is waiting to be paid. So don't flip access back on just because the API call didn't throw. Check the returned status, or wait for customer.subscription.resumed.

One small trap: if the customer has a coupon, it keeps counting down during the pause. A three month launch discount paused for three months is just gone when they come back. If you promised it, you'll need to fix that by hand.

What your app checks

This is where most of the bugs are. Stripe recommends using the subscription status to start and stop service. So:

Collection paused → status is still active → your paywall lets them in. That's what you want for a grace period.
Subscription paused → status is paused → your paywall should let them read their stuff but not use the paid features. Your call, but decide it before the first pause, not during.

The other catch: paused isn't only from a pause request. A trial that ends without a card can also put a subscription in paused. If your app shows "Add a card to continue your trial" for every paused, your photographer gets told their trial ended. Stripe gives you status_details.paused.subscription.type to tell them apart: pause_requested, trial_end_without_payment_method, system, and with the auto pause after payment failures added in the same release, first_payment_failure and final_payment_failure.

Rough version of the access check:

function access(sub: Stripe.Subscription) {
  if (sub.status === "active" || sub.status === "trialing") {
    return sub.pause_collection ? "full_grace" : "full";
  }
  if (sub.status === "paused") {
    const why = sub.status_details?.paused?.subscription?.type;
    if (why === "trial_end_without_payment_method") return "add_card";
    if (why === "first_payment_failure" || why === "final_payment_failure") return "fix_payment";
    return "paused_readonly"; // pause_requested, system
  }
  return "none"; // past_due etc. handled the way you already do
}

(Check the field names against your SDK version, status_details came with the newer API versions.) I went through what every status should mean for access in how Stripe's subscription statuses map to access, and paused was the one most paywalls forget.

The customer can't do this themselves (yet)

In Stripe's Customer Portal configuration docs there are toggles for switching plans, quantities, cancelling, cancellation reasons and retention coupons. I didn't find a pause option. So under 50 customers, a pause usually starts as an email to you, and that's fine. A support email at this size is a conversation, and it's often the only time a quiet customer tells you how they use the thing.

If you do want pause as self serve, put it in your own cancel flow. Offer it only when the reason fits (seasonal, project ended, taking a break) and never as a wall in front of the cancel button. I wrote more about a cancel flow that offers pause without dark patterns, and the short version is: pause is for "not right now", cancel is for "not for me", and mixing them makes people angry later.

A pause policy you can write in ten minutes

Write this down once, in a note, before the second pause request:

Which pause. "Away / not using it" gets a real pause. "Can't pay right now but still using it" gets paused collection, with mark_uncollectible if you're forgiving and keep_as_draft only if you said they'd pay later.
Max length. Something like up to 3 months, with a resume date always set. "Until you resume it" is how pauses turn into forgotten accounts.
What they see while paused. Read-only, export still works, nothing deleted. Say this in the reply.
What the first invoice after looks like. If you keep the default credit, tell them the first charge in March will be smaller than usual, or they'll think it's a mistake.
Coupons. Mention it if a discount will run out during the pause.
Reminder. Put a calendar reminder a few days before the resume date and send a short "you're back on March 1, here's what you'll be charged" email. I didn't see anything in the pause docs about Stripe emailing the customer before a resume, so I'd send this one yourself.

The reply to the photographer then writes itself:

"Sure, I've paused your subscription from today until March 1. You won't be charged before then and your projects stay as they are, you can still log in and look at them. Your first charge in March will be a bit lower because of the unused days from this month. I'll email you a few days before."

That's it. No retention trick, no form.

Quick checklist

[ ] Know which pause you're using: pause_collection (stays active, invoices still created) or real pause (paused, no invoices)
[ ] For pause_collection, pick behavior on purpose, and set resumes_at
[ ] Look at open invoices before pausing, old ones keep retrying
[ ] For real pause: flexible billing mode, charge_automatically, no trial, no schedule
[ ] Resume with resume_on_payment_success, confirm status before giving access back
[ ] Paywall handles paused and reads status_details so a paused customer doesn't see trial copy
[ ] Coupons keep running during a pause
[ ] Reminder email before resume

Stripe's pause subscriptions docs are the source of truth for the fields above, and the pages changed recently, so check them before you build anything. And since the same release also lets Stripe pause a subscription automatically after a failed payment, it's worth deciding how that fits with your retry emails. I put together a longer playbook on recovering failed payments before they turn into churn if you're setting that up anyway.

So, a question for anyone already doing this: when a customer asks to pause, do you use pause_collection, the newer pause, or do you just cancel and re-subscribe them later? And if it's pause_collection, which behavior did you go with?

When a Customer Asks for an Invoice With Their VAT Number and You Have Under 50 Customers

Posting Dude — Fri, 23 Oct 2026 05:15:44 +0000

Say you have 30-something paying customers and one of them, a small agency in Germany, sends this email on a Monday:

"Hi, can you resend last month's invoice with our company name and VAT number on it? Our accountant needs it. VAT ID is DE..."

It feels like a two minute job. Then you find out Stripe won't let you edit that invoice, and you also start wondering if you were supposed to charge them VAT in the first place.

This post is the Stripe side of that email. What you can fix for the past invoice, how to make every future invoice right without touching it again, and the tax question you should take to an accountant instead of guessing. I'm not an accountant, so expect a few "check with yours".

Why the customer actually cares

For a business buyer an invoice is not a nice PDF, it's a document their bookkeeping depends on. The European Commission's invoicing rules list what a full VAT invoice should contain: date, a unique sequential number, both parties' full names and addresses, the customer's VAT number if the customer is the one liable for the tax, and the words "reverse charge" when the reverse charge applies.

So when the agency asks for their VAT number on the invoice, they're doing exactly what any decent bookkeeping setup tells them to do. I wrote a guide to setting up bookkeeping as a solo founder and one of the rules in it is the same thing from the other side: if you're VAT registered, make sure the invoices you receive show the vendor's tax details. Your customer is following that rule. Your invoice is the thing in their way.

First, check what they got

Two different documents get mixed up here.

Subscriptions generate invoices automatically. If they pay you monthly through Stripe Billing, there is an invoice for every period already.
One-time payments through Checkout don't get an invoice by default. They get a receipt. Stripe's receipts doc says you need to enable invoices for one-time payments, by setting invoice_creation[enabled]=true when you create the Checkout Session.

If you sell a one-off thing (a lifetime deal, a setup fee, credits) and you never turned that on, the customer only has a receipt. For a business buyer that's often not enough, so turn it on before the next sale.

The old invoice: you probably can't edit it

This is the part that surprises people.

When an invoice is finalized, Stripe copies the customer's tax details onto it. The Invoice API reference says the customer_tax_ids field matches customer.tax_ids until the invoice is finalized, and after that it's no longer updated. So adding the VAT number to the customer today does nothing to last month's PDF.

And you can't just revise it. Stripe's doc on editing finalized invoices says:

invoices attached to subscriptions can't be revised after finalization (the Edit invoice button is disabled)
invoices in paid or void status can't be revised at all

Last month's subscription invoice that already got paid is both. Stripe also notes that in the EU you might want to void an invoice and issue a credit note instead of revising the original, and it tells you to ask your legal counsel.

What I'd do with under 50 customers:

Add the VAT number and legal name to the customer now (next section), so the next invoice is right.
Reply honestly: "Done for all future invoices. For last month's, I'm checking with my accountant on the correct way to reissue it."
Ask your accountant whether a credit note plus a new invoice is needed, or whether the corrected next invoice is fine for them. The answer depends on your country, not on Stripe.

What I would not do is download the PDF and edit it in a PDF editor. Now you have an invoice that doesn't match your Stripe records or your accounting, with the same number as a different document.

Add the tax ID to the customer

In the Dashboard, open the customer, click the pencil next to Details, scroll to the Tax status and Tax ID fields, and add an ID with type and value. While you're there, set the name to their legal business name and fill in the billing address. Both names and addresses are on the EU list above, and the PDF shows what's on the customer.

With the API it's one call:

curl https://api.stripe.com/v1/tax_ids \
  -u "sk_live_...:" \
  -d type=eu_vat \
  -d value=DE123456789 \
  -d "owner[type]=customer" \
  -d "owner[customer]=cus_..."

You can't edit a tax ID. To change one, you delete it and create a new one.

Then Stripe checks the number. Per Stripe's page on customer tax IDs, EU VAT numbers get validated against the European Commission's VIES system and UK VAT numbers against HMRC. It's asynchronous: it usually takes a few seconds, Stripe retries if the government service is down, and you get a customer.tax_id.updated event with verification.status set to pending, verified, unverified or unavailable.

Three details from that page worth knowing:

Valid number doesn't mean right company. VIES only says the number is valid. You still need to check the name and address match. In the Dashboard you can hover over the VAT number to see what VIES returned, including the registered name and address.
unverified is your call. Stripe reports the result. What you do with a number that fails is up to you and your compliance needs. When it says unavailable, you have to verify by hand.
Stripe doesn't keep re-checking. It validates when you add the ID, not over time.

For testing, Stripe has magic numbers. With an EU VAT, GB VAT or ABN type, 000000000 verifies, 111111111 fails, and 222222222 stays pending forever.

Stop doing this by email

One customer asking is a support ticket. Five is a missing field in your checkout.

If you use Stripe Checkout, set tax_id_collection[enabled]=true on the session. Checkout then shows fields for the tax ID and legal business name when the customer's location is supported. Some details from Stripe's Checkout tax ID doc:

The customer can enter one tax ID.
It's for business tax IDs only.
If you pass an existing Customer, also set customer_update[name]=auto so the business name they enter gets saved as the customer's name.
If that customer already has a saved tax ID, Checkout won't show the form again.
During the session Stripe only checks the format. The real validation happens after, and checkout.session.completed can arrive before it finishes. So don't decide anything tax-related in that webhook on the assumption it's verified.
tax_id_collection[required]=if_supported makes it mandatory in supported countries. For a mostly-individual customer base I'd leave it optional, or you're adding a field nobody can fill.

For customers who are already subscribed, the Customer Portal has a Tax ID option that lets them update it themselves. It's off by default. If you have the portal running already (I wrote about turning on Stripe Customer Portal before 50 customers), flip that one on once you have any business buyers.

Your own tax ID goes on the invoice too

The EU list includes the supplier's details, so if you have a VAT or GST number, put it on your invoices. In the Dashboard it's Invoice settings, the Tax tab, add your ID, then use the overflow menu to set it as default. Default tax IDs then show on your invoice and credit note PDFs unless you override them per invoice.

Same snapshot rule: you can't add, change or remove account tax IDs on an invoice after it's finalized. If you've been sending invoices without your number, the fix only applies going forward.

The question behind the question: did you owe VAT?

This is where you stop and call an accountant. But here's what Stripe does and doesn't do, so the conversation is short.

Reverse charge. Stripe's EU tax page explains it simply: in some cases when you sell services to a VAT-registered business in another EU country, the customer calculates and pays the VAT, and your invoice should say reverse charge instead of showing a tax amount. If the customer gives a domestic tax ID (same country as you), reverse charge doesn't apply and it's treated like a consumer sale.

If you use Stripe Tax, it treats a customer with a valid-format EU VAT number as reverse charge and doesn't calculate tax. Note the wording on Stripe's tax ID page: Stripe Tax applies the reverse charge when the tax ID has the required number format, regardless of the government verification result. So an unverified number still gets zero tax unless you do something about it. Another reason to look at the VIES result yourself.

If you don't use Stripe Tax, there's a customer-level setting. On the Customer object, tax_exempt can be none, exempt or reverse, and when it's reverse, invoice and receipt PDFs include the text "Reverse charge". It's a label. It doesn't make a sale reverse-chargeable, it only prints the words.

Stripe Tax only calculates where you're registered. If you have no registration for a location, the calculation returns zero tax, with taxability_reason set to not_collecting. So turning on Stripe Tax doesn't mean you're collecting anything yet. You add registrations in the Dashboard after you've actually registered with the tax authority. As I write this, Stripe's pricing page lists 0.5% per transaction where you're registered for the no-code integrations (Billing, Checkout, Invoicing, Payment Links). Check your own country's page.

Where the money question really sits. The B2B sale to the German agency is often the easy case. The harder one is consumers. Stripe's EU page says that if your business is outside the EU, you might need to register to collect VAT from your first sale in an EU country, and it describes the non-Union One Stop Shop scheme for non-EU businesses selling services to individuals, so you file one return instead of one per country. EU-based businesses have a 10,000 EUR a year threshold: under it (and a couple of other conditions), cross-border sales to individuals can stay on home-country VAT. Stripe's Thresholds page in the Tax Dashboard can show you where you're getting close, but it only highlights potential obligations. Confirming them is on you.

If reading that paragraph makes you tired, that's the honest case for a merchant of record. With an MoR the provider is the legal seller, so it handles VAT and sales tax on its own invoices, for a higher fee per sale than plain Stripe. I compared Stripe and merchant of record options in a guide about charging for a side project, with the fees as they were in October. Small SaaS with lots of individual buyers abroad is exactly where it's worth a look.

A short checklist for the next VAT email

Reply the same day: future invoices will be fixed, the past one is with your accountant.
Add tax ID, legal name and billing address to the Customer.
Check the VIES result and the registered name in the Dashboard.
Add your own tax ID in Invoice settings and set it as default.
Turn on invoice_creation for one-time Checkout payments.
Add tax_id_collection[enabled]=true to Checkout, with customer_update[name]=auto for existing customers.
Turn on the Tax ID option in the Customer Portal.
Book one call with an accountant about registration, reverse charge and how to reissue old invoices. Bring a list of your customers by country.

None of this is exciting, but it's maybe an hour of work, and it turns "can you resend the invoice with our VAT number" into an email you never get again.

So, a narrow question for anyone selling to businesses: do you collect VAT IDs in Checkout with tax_id_collection, or do you still add them by hand when someone emails? And if you made it a Checkout field, did anyone actually fill it in?

When Bots Start Card-Testing Your Checkout and You Have Under 100 Customers

Posting Dude — Thu, 22 Oct 2026 05:15:02 +0000

Say you open the Stripe dashboard on a Tuesday morning and the home chart has a spike you didn't earn. Two hundred payment attempts overnight, almost all failed, a few succeeded for your $1 starter plan. The customer names look like someone fell on a keyboard. Your actual business does maybe 40 payments a month.

That's card testing. Someone has a list of stolen card numbers and is using your checkout to find out which ones still work. Your product doesn't matter to them. Your form is just a cheap way to ask a bank "is this card alive?"

With under 100 customers this hits harder than it does for a big store. Your normal traffic is so small that a few hundred junk attempts can make your whole account look risky. So set a few things before launch day, not after the first spike.

I wrote earlier about the signup side of this, fake accounts and junk signups. This one is only the Stripe part.

What card testing looks like in Stripe

Stripe's own guide to protecting yourself from card testing lists the symptoms:

a spike in failed or blocked payments on the dashboard home page and the transactions list
a spike of 402 errors in your developer logs, a lot of them with generic_decline
small payments that succeeded, usually with nonsense names and emails

For a small SaaS I'd also look for:

one Customer object with many different cards attached
lots of new Customers created from the same IP in a short window
a pile of SetupIntents with no subscription ever starting after them

That last one matters. Stripe says testers prefer card setup flows, because validating a card during setup usually doesn't show up on the cardholder's statement, so the real owner doesn't notice. A "start your free trial, card required" form is a card setup flow. So is "add a payment method" on a settings page that anyone can reach.

Why tiny SaaS checkouts are a nice target

Small products tend to have exactly what testers look for:

Free trial with card up front. A SetupIntent or a $0 trial checkout checks the card and charges nothing. Perfect for them.
$1 or very cheap plans. Testers like low amounts because cardholders are less likely to notice.
An open endpoint that creates PaymentIntents, SetupIntents or Checkout Sessions. If any visitor (or any script) can hit /api/create-checkout-session without logging in, that's a card checker with your name on it.
Low volume. Your normal decline rate is built on a tiny base, so a burst moves it a lot.

Stripe also says testers can use your publishable key against your site, and that simple IP blocks alone usually aren't enough.

What Stripe already does before you touch anything

If you use Stripe Checkout or the latest Payment Element, Stripe runs card testing controls on its side: rate limiters, AI models, CAPTCHA triggers when it detects an attack. Payments it stops show up as Blocked by Stripe. A hand-rolled card form against the raw API gets less of that.

On plans: Stripe's Radar pricing page lists Radar Lite as included at no extra charge on standard payments pricing, with AI-based fraud prevention for card payments, card testing prevention and fraud alerts. Card testing prevention is in every tier. What you don't get on the free tier, or on Radar Standard, is custom rules with backtesting. Those are in Radar Plus and Radar Pro (if you've read older posts that say "Radar for Fraud Teams", that's the feature set they mean). As I write this, the US page shows Plus starting at $14 a month or pay as you go. Check your own country.

Two cheap things that help the default protection work better:

Send Stripe more data. Stripe says the models do better when you pass IP address, email, name and billing address, and it recommends loading Stripe.js on every page, not only checkout.
Turn on Radar for saved cards. Per Stripe's page on optimizing Radar risk factors, Radar by default does not scan when you set up a payment method for future use without a charge. If your free trial collects a card with a SetupIntent, go to Radar settings and enable "Use Radar on payment methods saved for future use". Otherwise your trial form is the one door Radar isn't watching.

While you're there, check the built-in CVC and postal code risk-score rules. Stripe says they also apply when attaching a card to a customer, so they help setup flows too.

Radar rules worth adding (if your plan has custom rules)

Rules use this shape: {action} if {condition}. The rules reference has the details. Three things from it worth knowing before you write anything:

Velocity counts exclude the payment being evaluated. So total_charges_per_ip_address_hourly is 0 on the first attempt from an IP in the hour, 1 on the second.
"Hourly" isn't exactly 60 minutes. Stripe uses 5-minute buckets, so it can be up to 3,900 seconds.
Rules only affect future payments, not ones already processed.

Stripe's Radar Rules 101 guide gives these two as card testing rules:

Block if :total_charges_per_ip_address_hourly: > 1
Block if :blocked_charges_per_ip_address_hourly: > 1

The second one is the "more aggressive" add-on. For a B2B SaaS where a whole office might share one IP, > 1 on the first rule can be too tight, so backtest it before turning it on.

Since the trial is usually the weak spot, also use attributes that count SetupIntents. In the supported attributes list, card_count_for_ip_address_transactions_hourly counts cards from "transactions (charges and SetupIntents)", while card_count_for_ip_address_hourly only counts charges. Some starting points (the thresholds are my guess for a small SaaS, not Stripe's numbers):

Block if :card_count_for_ip_address_transactions_hourly: > 3
Block if :card_count_for_customer_daily: > 2
Block if :declined_charges_per_ip_address_hourly: > 3
Request 3D Secure if :is_setup_intent: and :risk_level: != 'normal'

Plain version: one IP trying four-plus cards in an hour, or one customer with three-plus cards in a day, is not a real customer. Someone who typos their card twice still gets through.

So these don't bite you:

The card count attributes are bounded at 25, so don't write rules that need numbers above that.
The rule editor tests a rule against past payments, and a traffic allocation of 0% runs it in shadow mode, reporting what it would have done. With thin history, a week in shadow mode is a decent sanity check.
Be careful with :cvc_check: in your own custom rules. It's a post-authorization attribute, and Stripe notes the cardholder may briefly see an authorization even if the charge ends up blocked. The built-in risk-score CVC rule is the easier option.

Fix your own endpoint, because Radar only sees what reaches Stripe

Radar can't stop your server from creating thousands of Checkout Sessions or Customers for a script. That part is on you.

Require login (and ideally a verified email) before you create anything in Stripe. Stripe's guide says the easier it is to reach your payment form, the easier card testing gets. Don't create a Stripe Customer at signup "just in case". Create it when a verified user actually goes to pay or start a trial.
CAPTCHA on the endpoint that creates the PaymentIntent, SetupIntent or Checkout Session, checked on the server. Stripe's troubleshooting list for a CAPTCHA that isn't working starts with: require it on every request that leads to a card validation or payment, and check it server side.
Rate limit that endpoint per IP and per account. Stripe's own example is limiting how many new customers one IP can create in a day. Their combined idea is nice too: let the first attempt from an IP through with no friction, then require a CAPTCHA for that IP for the next few hours.
Limit cards per account. Real customers add one card, maybe two.
Think about a trial without a card. If card-required trials are not core to your model, Checkout supports free trials without collecting payment details using payment_method_collection=if_required, with trial_settings.end_behavior.missing_payment_method deciding whether to cancel or pause when the trial ends. No card form at signup, nothing to test. It's a conversion tradeoff, your call.
Keep your secret key secret. If it leaks, testers can create payments and set up cards directly with it, and none of your front-end defenses matter.

If it's happening right now

Stripe's active card testing checklist is short: identify it, refund the fraudulent payments, add mitigations or move to a recommended integration, then keep monitoring. In practice for a small SaaS:

Close the door first. Put the checkout or trial endpoint behind login, turn on the CAPTCHA check, or temporarily switch off card-required trials. Ugly is fine for a day.
Refund the junk payments that succeeded. Stripe recommends refunding suspicious payments that got through, so they don't become early fraud warnings or disputes. If you use manual capture, cancel the uncaptured ones instead of capturing them.
Don't retry the fake cards. Stripe calls this out: if your dunning keeps retrying cards attached to fraudulent customers, you're repeating the attack from your side. Cancel the fake subscriptions and clean up those customers.
Add the velocity rules above if you have custom rules, in shadow first if you can afford to wait, straight to block if you can't.
Contact Stripe support and tell them it's card testing. They can see things on their side you can't.
Check the 402 graph for a few days to make sure it actually stopped and didn't just slow down.

Why it's worth an hour before launch

Stripe's guide lists the consequences, and none are about the few dollars of test charges:

Disputes and early fraud warnings from the payments that went through. At under 100 payments a month, one dispute is already a 1% dispute rate, so a handful of them is a real problem.
Higher decline rates for your real customers, even after the attack stops, because issuers start seeing your business as riskier.
Extra fees, like dispute fees, and authorization fees if you're on a custom pricing plan.
Card monitoring programs if the fraud warnings and disputes pile up.
Junk data. Fake trials look like growth.

And there's the account itself. A small account that suddenly looks risky is how reviews and payout holds start. There's a longer piece on keeping your indie SaaS from getting locked out of Stripe and other critical accounts worth reading before that day.

Pre-launch checklist

[ ] Checkout or Payment Element, not a hand-rolled card form, if you can
[ ] Stripe.js loaded on every page, and IP, email, name, billing address passed to Stripe
[ ] "Use Radar on payment methods saved for future use" turned on if trials collect a card
[ ] Built-in CVC / postal code risk-score rules reviewed
[ ] No Stripe Customer, PaymentIntent, SetupIntent or Checkout Session created before login + email verification
[ ] Server-side CAPTCHA and per-IP / per-account rate limit on that endpoint
[ ] Max cards per account
[ ] If you're on Radar Plus or Pro: velocity rules in shadow mode, then block
[ ] A saved filter or alert for failed payments and 402s, so you see a spike the same day
[ ] Secret key only on the server, never in a repo or front-end bundle

None of this is security or legal advice, just the Stripe settings I'd check before putting a checkout link in front of a launch crowd.

One question for people who already run a card-required free trial on Stripe: did you turn on Radar for SetupIntents, and if so, did it block real trial signups or only the junk?

When a Customer Switches Plans Mid-Month and You Have Under 50 Subscribers

Posting Dude — Wed, 21 Oct 2026 05:13:06 +0000

Say a customer on your $19/month Starter plan emails on the 16th: "can I move to Pro today? I need the export thing." You open Stripe, swap the price on their subscription, and reply "done".

What did they just pay? Nothing yet, most likely. And on the 1st they'll get an invoice for $64 instead of $49, and you'll get an email asking why.

That's proration. It's not a bug, it's Stripe doing exactly what the default says. But when you have under 50 subscribers, every one of these plan changes is a support thread with your name on it, so it's worth knowing what each switch actually charges before you click. This is the version I'd want: upgrades, downgrades, monthly to annual, the four traps, and how to check the number before the customer sees it. Not tax or accounting advice.

All numbers below use a 30-day month to keep the math readable. Stripe prorates to the second, so real invoices will be a few cents off.

The default: credit the old plan, charge the new one, bill it later

Stripe's proration docs describe it as two lines. When a plan changes mid-period, the customer gets a credit for the unused time on the old price, and a charge for the remaining time on the new one.

For the Starter to Pro upgrade on day 15:

Line	Amount
Unused time on Starter ($19 x 15/30)	-$9.50
Remaining time on Pro ($49 x 15/30)	+$24.50
Net proration	+$15.00

The part people miss is when that $15 gets billed. The default proration_behavior is create_prorations, which creates those two lines as pending items and puts them on the next invoice. So on the 1st the customer sees $49 for the new month plus the $15 adjustment. $64. Correct, but nobody expects it.

You have three settings per update:

create_prorations (default): calculate the adjustment, bill it on the next renewal.
always_invoice: calculate it and invoice it right now. The customer pays $15 today and $49 on the 1st. Much easier to explain.
none: no adjustment. They pay the full new price from the next invoice. There's no setting that turns prorations off for a subscription for good, you pass none on every request that would prorate.

For upgrades at this size I'd use always_invoice. "You paid $15 today for the rest of this month, normal $49 from the 1st" is one sentence in a reply. "Your next invoice includes a proration adjustment" is a follow-up email.

Downgrades: the credit doesn't go back to their card

Now flip it. A Pro customer drops to Starter on day 15:

Line	Amount
Unused time on Pro	-$24.50
Remaining time on Starter	+$9.50
Net proration	-$15.00

With the default, that -$15 lands on the next invoice: $19 minus $15, so they pay $4 next month. Stripe's docs are clear that negative prorations aren't automatically refunded. The credit reduces what they owe next, it doesn't go back to the card. If they cancel before the next invoice, you have a credit sitting on a customer who's gone, and you're deciding manually whether to refund it.

Most tiny SaaS don't need any of that for a downgrade. The cleaner policy is "you keep Pro until the end of the month you paid for, then you're on Starter". No credit, no $4 invoice, nothing to explain.

In Stripe that's a subscription schedule, not a normal update. The documented pattern is two calls: create a schedule from_subscription, which gives you one phase matching the current period, then update it with a second phase on the cheaper price. The second phase starts when the current one ends.

Two things the docs warn about that are easy to get wrong:

When you update the schedule, pass the whole current phase again (price, quantity, discounts, metadata). Stripe unsets anything you leave out.
Once a schedule is attached, change the subscription through the Schedules API, not the Subscriptions API. Some direct changes can get overwritten at the next phase transition. Store the schedule ID next to the subscription ID.

If you use Customer Portal, there's a "Manage downgrades" setting that does the schedule for you at the end of the billing period. It only works between prices on the same product, and it creates a schedule you then need to respect the same way. I went through the portal settings I'd start with in turning on Stripe Customer Portal before 50 customers, the plan-switch part pairs with this.

Monthly to annual: the one that bills today

This is the switch you actually want people to make, and it behaves differently from the other two. Stripe's guide on changing prices says when the old and new price have the same billing period, the billing dates stay the same. When the period changes, like monthly to yearly, the new price is billed at the new interval starting the day of the change.

So say a Starter customer on day 10 switches to a $190/year plan. On a classic-mode subscription:

Line	Amount
Unused time on monthly Starter ($19 x 20/30)	-$12.67
Annual Starter, starting today	+$190.00
Charged today	$177.33

And their renewal date moves to today, next year. If you send them a "you're on annual now" note, say that, because the date they're used to just changed.

If you pass none here, the API reference says there's no credit for the unused monthly time, but the billing date still resets and they still get charged the full $190 today. So they pay for 20 days twice. Leave proration on for this one.

There's a catch if your subscriptions are on Stripe's newer billing mode, which I'll get to below: there, the billing cycle anchor is never reset automatically. If you want "annual starts today and charges today", ask for the anchor reset explicitly on the update and preview the result first.

I'm biased here, I think an annual option belongs on the pricing page way earlier than most founders add it. I made that case in this piece on adding an annual plan before you think you need one. But the switch itself is the part that generates support email, so test it before you promote it.

Four traps I'd check before the first plan change

1. Pass the subscription item ID or you'll bill both plans. The change-price docs say this twice for a reason: if you update the subscription with a new price but don't specify which item it replaces, Stripe adds the new price as a second item. Now the customer is on Starter and Pro at once. Same page: changing the price resets the quantity to 1 unless you pass it again. If you sell seats, a 5-seat team becomes a 1-seat team.

2. Unpaid invoice plus a plan change can credit time they never paid for. Stripe calculates prorations assuming earlier invoices will eventually be paid. If a customer is past_due and downgrades, the credit for "unused" time on the expensive plan can be for time that was never paid. The docs suggest proration_behavior=none when the latest invoice is unpaid, and voiding the old invoice if you bill again, so they don't pay twice.

3. Charging now doesn't mean the change waits for the money. With always_invoice, if the card fails, the update still goes through and the subscription goes past_due. So the customer has Pro and you have a failed invoice. If you'd rather the upgrade only happen once it's paid, use payment_behavior=pending_if_incomplete. Stripe holds the change as a pending update and applies it when payment succeeds. It expires after 23 hours (or earlier, at the trial end or period end if those come first), and then the invoice is voided.

4. Discounts and prorations don't stack the way you'd guess. Stripe calculates proration amounts from the discounted price, but the proration lines themselves are marked not discountable. So if someone is on a launch coupon and upgrades, the credit and the charge both already reflect the coupon, and the coupon won't knock anything more off those lines.

Check which billing mode your subscriptions are on

This one is easy to miss. Stripe now has two billing modes, classic and flexible, and they prorate differently. Per Stripe's comparison page:

In classic mode, a credit proration is based on the item's current price. Their example: upgrade with none, then downgrade 10 days later, and classic credits time on a price the customer never paid. Flexible credits what was actually billed.
Classic resets the billing anchor automatically when you switch to a different interval. Flexible never does unless you ask.

Which one you get depends on how the subscription was created. For API version 2025-09-30.clover and later the default is flexible. Earlier versions default to classic. Subscriptions made in the Dashboard (and Payment Links and pricing tables made there) use the default set in your billing settings. You can migrate a subscription from classic to flexible, but not back.

So before you write any plan-change code, open one real subscription and look at billing_mode. A lot of older proration examples online assume classic.

Preview the number before the customer sees it

Stripe lets you preview the next invoice with the change applied, without changing anything. Pass a proration_date so the preview and the real update use the same second, otherwise the amount drifts a little between the two calls.

PRORATION_DATE=$(date +%s)

curl https://api.stripe.com/v1/invoices/create_preview \
  -u "$STRIPE_SECRET_KEY:" \
  -d customer=cus_123 \
  -d subscription=sub_123 \
  -d "subscription_details[items][0][id]=si_123" \
  -d "subscription_details[items][0][price]=price_pro_monthly" \
  -d "subscription_details[proration_date]=$PRORATION_DATE" \
  > preview.json

# just the proration lines, in dollars
jq -r '.lines.data[]
  | select(.parent.subscription_item_details.proration == true)
  | "\(.amount / 100)\t\(.description)"' preview.json

jq '.amount_due / 100' preview.json

With the Starter to Pro example, the first jq prints the -9.5 and 24.5 lines, and the second prints 64, because the preview shows the next invoice under the default behavior (adjustment plus the new month). If you're going to use always_invoice, the proration lines are the part that gets charged today.

Then send the real update with the same proration_date:

curl https://api.stripe.com/v1/subscriptions/sub_123 \
  -u "$STRIPE_SECRET_KEY:" \
  -d "items[0][id]=si_123" \
  -d "items[0][price]=price_pro_monthly" \
  -d proration_behavior=always_invoice \
  -d "proration_date=$PRORATION_DATE"

Run all three switches once in test mode with a test clock, so you've seen each one end to end before a real customer asks.

What I'd actually set up under 50 subscribers

Upgrades: always_invoice, plus pending_if_incomplete if you only want to unlock after payment.
Downgrades: at period end, through a schedule (or the portal's "Manage downgrades").
Monthly to annual: proration on, explicit anchor reset if you're on flexible, preview first.
Your app's access follows the webhook, not your "done" reply. Upgrade unlocks when the subscription update lands, downgrade locks when the next phase starts.
One short confirmation email after every change: old plan, new plan, what they paid today, what the next invoice will be and when. If you don't have one yet, this breakdown of the billing emails that cut support tickets covers the plan-change one.

That's most of it. None of this is hard, it's just that the default does something reasonable that nobody explains to the customer.

If you handle plan changes on Stripe already: do you prorate downgrades and let the credit show up on the next invoice, or make everyone wait until the end of the period they paid for?

Every IndieHunt launch now has a public /live page: verified upvotes, guest votes shown apart and not counted, outbound clicks, comments, rank this week. Nothing on it is estimated. https://indiehunt.io/project/toolverified/live?utm_source=devto

Posting Dude — Mon, 19 Oct 2026 05:42:17 +0000

ToolVerified live launch stats

ToolVerified is an artificial intelligence tool. A hand-checked directory of new tools, each reviewed by a person before it publishes Freemium pricing.

indiehunt.io

DEV Community: Posting Dude

Chrome Blocked 8 eMudhra CA Keys on Oct 17. A Node Release From Oct 14 Still Trusts Them.

What actually happened, briefly

The test

Why patching the OS didn't help

Where the old copies are hiding

An 18-line check for any machine or image

Is your own site's certificate affected?

The fix list

Your Login Page's ?next= Check Probably Lets /%09/evil.com Through. 10 Strings to Test It With

Why the check fails

I ran 10 strings through two checks

This bug has shipped in real auth tools

Framework notes

The checklist

A Canonical in Your Next.js Root Layout Lands on Every Page. 6 Ways a Canonical Quietly Cancels Itself

1. A canonical in a shared layout gets inherited by every child page

2. Adding hreflang (or anything under alternates) deletes the inherited canonical

3. Relative paths, and the ./ thing

4. Two canonical tags

5. A canonical that points at a 404, a redirect, or a noindex page

6. The canonical ends up in <body>

Bonus: og:url that disagrees

PDFs: the Link header

The quick check

After you fix it, check what Google actually picked

The rule I'm keeping

One Old CNAME Let Spammers Send Mail as marthastewart.msn.com. Check Your Old Subdomains.

Three ways a subdomain ends up pointing at someone else

What someone actually gets

Step 1: list every hostname you have

Step 2: check every name by hand once

Step 3: check all of them with a script

Step 4: check your SPF includes

Step 5: fix it, in the right order

The 15-minute version

76 of 77 trivy-action Tags Were Repointed in One Night. Some SHA Pins Didn't Help Either.

Three incidents, same shape

Three ways a pin fails

Step 1: list what you actually run (10 min)

Step 2: delete before you pin (10 min)

Step 3: pin, and check the pin is honest (15 min)

Step 4: or try the new lockfile (15 min)

Step 5: make a stolen run worth less (10 min)

Step 6: if you ran a bad version

The rules I'd actually adopt

Let's Encrypt Goes to 64-Day Certificates in February. Grep Your Server for 60, 80 and 83 First.

The dates, in one place

Why a tiny SaaS should care more than a big one

Step 1: find out what actually renews your certs

Step 2: grep for the hardcoded numbers

Step 3: renewal isn't deployment

Step 4: check the certificate people actually get, from outside

Step 5: find the certs you forgot about

Step 6: if anything still renews by hand, fix that now

Step 7: try the short certs early, on something that doesn't matter

The one-hour version

When a Customer Asks to Pay by Invoice Instead of a Card and You Have Under 50 Customers

What "pay by invoice" means in Stripe

The trap: "active" doesn't mean "paid" anymore

How bank transfers actually land

The fee math (why finance teams ask for this)

When they pay straight into your bank

Moving an existing card customer to invoices

What happens when they don't pay

A small invoicing policy

Quick checklist

When a Customer Asks to Pause Their Subscription and You Have Under 50 Customers

Stripe has two kinds of pause now

The easy one: pausing payment collection

The real pause: status becomes paused

Why the pause button might be greyed out

Resuming without a surprise

What your app checks

The customer can't do this themselves (yet)

A pause policy you can write in ten minutes

Quick checklist

When a Customer Asks for an Invoice With Their VAT Number and You Have Under 50 Customers

Why the customer actually cares

First, check what they got

2. Adding hreflang (or anything under `alternates`) deletes the inherited canonical

3. Relative paths, and the `./` thing

6. The canonical ends up in `<body>`

The real pause: status becomes `paused`