Findings · 2026-09-01 · By VSNARY | Emmanuel Orta
Our placeholder check accused a newspaper of publishing NaN. The NaN was in a URL.
A self-audit rule that scans every stored record for the token NaN found three of them. All three were inside the letters of one URL slug.
The scanner keeps a list of strings that should never reach a customer-facing surface: [object Object], undefined/, "null/, [native code], and NaN. Each one has shipped at least once, which is why the list exists. After every scan the self-audit serialises the whole record and counts them, and a hit is filed as PLACEHOLDER_IN_RECORD at severity 3: a bug in us, quarantined before anyone reads it.
It fired on a national newspaper's record. 3 occurrence(s) of NaN in the stored record. We opened the record expecting a broken calculation. The three occurrences were all in one place: a sitemap excerpt, inside a URL slug for a live blog, in a string like /QtNaNj2NkpSp/. A random identifier happened to contain the letters n, a, N in that order.
A substring is not a token
The check split the serialised record on the literal string and counted the pieces. That finds NaN wherever it occurs, including inside a longer run of letters that has nothing to do with a number. The detector was doing exactly what it was written to do; what it was written to do was too broad.
The fix is a boundary: NaN counts only when it is a whole token, not preceded or followed by a letter or digit. A real leak looks like NaN% or NaN ms or : NaN,, and all of those still match. A base-62 identifier that happens to spell it does not. The same class of fix that counting @id strings needed: a string that appears is not a fact that holds.
Why a false positive in a self-audit matters
The self-audit cannot move a grade, so this cost the newspaper nothing. It cost us something specific: a detector that fires when nothing is wrong is a detector nobody reads, and the whole point of this one is to be read. The first version of the self-audit fired on every real record for a different reason, and the lesson then was the same. Precision in an alarm is not polish. It is the difference between an alarm and noise.
Verified on the next scan of the same site: three substrings still present in the record, zero whole-token matches, self-audit clean. The identifier is still in the sitemap, where it belongs.
The general rule for anyone scanning output for garbage
Placeholder scans are worth having. Every templating system eventually prints the name of a missing variable. But scan for tokens, not substrings: anchor on non-alphanumeric boundaries, and test the detector against a corpus of real records before trusting a hit. A URL, a hash, a base-64 blob, or a product code will eventually contain any short sequence of letters you can name. undefined is safer than NaN only because it is longer.
Every figure above came out of this scanner.
Point it at your own domain and see the same measurements, free.
Questions this post answers
What is a placeholder-in-record check?
A self-audit rule that serialises every stored scan record and searches it for strings that should never reach output: NaN, undefined, [object Object], null in a URL. A hit means the scanner leaked an unset value, and the record is flagged before a reader sees it.
Why did NaN match a URL?
The check counted the substring wherever it appeared. A random base-62 slug in a sitemap URL contained the letters n-a-N in order. The rule now matches NaN only as a whole token, not preceded or followed by a letter or digit.