Everything I got wrong
building one small tool.

Nothing. Nobody reported this and no request failed. I found it by attacking my own endpoint on purpose, because a public tool that fetches a stranger’s address is the one thing on this site worth attacking.

I added the string to the blocklist. That would have shipped, looked like a fix, and left every other spelling working.

The guard compared the hostname against a list of names. A trailing dot is a valid fully qualified way of writing the same host, so localhost. is not in any list of names. Neither is any domain that quietly points an A record at 127.0.0.1.

Nothing compares hostnames any more. The name is resolved, and the address that comes back is what gets judged.

A reviewer walked from the internet to a loopback server through the guard I had just written 74 tests for.

There was no first move, because I did not believe there was a bug. The table asserted that ::ffff:127.0.0.1 was refused and I read that as covered.

::ffff:7f00:1 is the same address written in hex. My table contained the spelling I had thought of, and the check contained the same spelling, so the test could only ever confirm what the code already did.

Eleven spellings of a v4-mapped address are asserted now, including ::ffff:a9fe:a9fe for the metadata service and ::7f00:1 for the v4-compatible form. One of the eleven is ::ffff:0808:0808, which is 8.8.8.8 and must still work, so the fix cannot pass by refusing everything.

The audit reported the social links on two live client sites as broken. If that had gone out, somebody sends a client a report, the client clicks the link, it works, and every other line on the page stops being believed.

I nearly special-cased Facebook. That fixes the one report I was looking at and leaves the same wrong verdict waiting for every other site that guards itself.

Facebook answers 400 to anything that is not a logged-in browser. So does facebook.com/nasa, which I used as a control. The tool was treating any failed request as proof of a dead link.

Only 404, 410 and 5xx count as gone. Everything else is "could not check from here" and is left out of the report entirely. Then four more of the same shape: HEAD lies, so ieca.org answers 404 to a HEAD and 200 to a GET, and any accusing verdict gets confirmed with a real GET. A timeout is usually a slow server, so it retries once at twenty seconds. A link to another website is not mixed content. A spam honeypot is meant to be hidden, so it is not an unlabelled form field.

Two real client sites scored 69 and 83 before those five fixes and 93 and 95 after them. Nothing about either website changed, so the whole of that gap was the tool being wrong.

An audit that ran out of time came back with a better number than the same audit finished properly.

I widened the deadline. Which makes it rarer and leaves the number wrong when it happens.

The score is 100 minus a weight for each finding. A check that never ran produces no finding, so cutting the run short quietly improves the result.

A short run now returns partial, lists exactly what it skipped, and sets scoreTrustworthy to false. The readme tells anyone building on it not to display the number when that flag is false.

Generated markup carried width="3" height="101" for an image that is 178 pixels square. It reached the output before anybody caught it.

The first fix read the opening tag properly and then read width="2em" as 2 pixels, which is a different wrong number arriving the same way.

The SVG reader searched from <svg to the end of the file, so it matched stroke-width="3" on a group and picked a height off a rectangle inside the drawing.

It reads the opening tag only, accepts pixel values only, and falls back to the viewBox when the width is not in pixels.

Everything compiled. The site threw at runtime.

The change that caused it was itself a fix, for a real problem: the built package could not be imported without .js on its relative imports. Adding them fixed the package and broke the bundler, and the type system had no opinion about either.

The two consumers of that code want opposite things from the same line, and neither of them is checked by tsc.

The source stays as the bundler wants it, and a post-build step rewrites the extensions in the output. Nobody has to remember.

The stylesheet check produced no findings, ever, on any site. It looked like sites were fine.

I read the check. The check was correct.

text/css was missing from the content-type list on the fetch, so the stylesheet body came back empty and the correct check ran on nothing.

One regex, and a test that asserts a stylesheet is actually fetched rather than asserting the check works when handed a string.

A menu page answering 429 was reported at the highest severity as a page that will not open. Also a members area answering 401, which is working exactly as designed, and anything behind a firewall answering 403.

Nothing, because the test suite looked complete. It asserted the timeout case and it asserted the 404 case, and both passed. No test asked about the space in between.

The rule that a failed request is not proof of a dead page was written down, agreed, and applied to outbound links only. The menu check still read status >= 400. The 429 is the one that stings: this crawler requests eight pages in a row, their server pushes back, and the tool then charges the owner for a status it produced itself.

One classifier, named classifyLink, used by both paths. The same failure as fixing a bug where it was reported instead of where it lives.

Found by the golden set on its first run, in the split it had never been tuned on. Six more tests now cover the statuses nothing had asked about.

A divider graphic carrying alt="" was listed as an image needing a description. An empty alt is the correct way to mark something decorative, because it tells a screen reader to skip it. Following that advice would have made every one of those pages worse for exactly the people the check exists to help.

None. Nobody reported it and nothing threw. A golden set caught it the first time it contained a decorative image.

The parser read the attribute as (attr || "").trim(), which turns "there is no alt attribute" and "the author deliberately wrote an empty one" into the same empty string.

The image carries hasAlt now, so a decision and an omission stop being the same value. Whitespace-only alt still counts as missing. Nobody types alt=" " on purpose.

The generated alt-text.md had the same bug and was handing people a list of decorative images to go and write descriptions for.

Every responsive image pulling an insecure source passed the mixed content check silently. The element was visited. Nothing was found.

I read the selector, saw [srcset] listed in it, and moved on. It looked handled.

The selector matched <source srcset="http://...">, and then the body read a src attribute that a <source> does not have. So the value came back empty and the check said nothing, which looks exactly like a page with no problem.

It reads srcset too, and splits the comma separated list, because each entry is a URL followed by a descriptor like 2x.

None. This one came out of a review, not a failure.

I fixed it in the file the review pointed at. There were three near-identical copies, and the same line was sitting in the other two.

Two holes. The table was cleared entirely once it passed 500 entries, so cycling 500 invented addresses reset everybody’s counter. And the key came from the leftmost entry of x-forwarded-for, which is whatever the caller typed, so one caller could look like unlimited visitors.

Eviction by age, never a wipe. The key comes from the header the platform sets and a caller cannot forge. One implementation, used by every public endpoint, because the real failure was fixing it where it was reported instead of where it lived.