Nobody else's code runs on your login page
Twenty-three front-end libraries were being fetched from two CDNs, two of them at whatever version was published that morning. They are all served from us now, and reCAPTCHA is gone because three months of logs showed it blocked our own test browser and nothing else.
A tool that reads every machine in an estate should be able to say exactly whose code runs in the browser looking at it. Until this morning the honest answer here was "ours, plus whatever two content delivery networks were serving".
Twenty-three libraries, now local
Every page was pulling front-end libraries from cdn.jsdelivr.net and cdnjs.cloudflare.com. Bootstrap, DataTables, the charting libraries, the syntax highlighter, the terminal emulator, and more. Twenty-three files in total.
Every one of those requests told a third party the IP address of the person using Wegweiser and the page they were reading. For a product whose pitch is care with client estates, and whose own subprocessor list does not include either CDN, that is not a defensible position. It is the same finding that moved our webfonts in-house earlier this month and removed a third-party IP geolocation call the week before.
All of them are served from our own server now, pinned by version, with checksums recorded in the repository.
Two of them had no version at all. The chart libraries were requested by package name, which means whatever those CDNs published that morning executed with full access to the page, on every device page, without anyone reviewing it. They are pinned to exactly what was being served, byte for byte, so nothing about the behaviour changed. Only who has to be trusted for it to keep working.
The policy the browser enforces now denies those hosts outright rather than merely not using them, so a library added carelessly in future fails loudly instead of quietly reopening the hole.
reCAPTCHA is gone
The login page ran Google's reCAPTCHA v3. It scored each attempt and refused anything below a threshold.
Three months of logs say what it caught: 130 blocked attempts, from exactly two addresses, and 129 of them were our own automated test browser. Not one recorded attacker. Over the same period a hidden field in the form, a trick that costs nothing and involves nobody, caught 61 bots.
It also failed closed. If Google was unreachable, or a token expired while somebody typed their password, nobody could sign in. That is an availability dependency on the single most important path in the product, in exchange for the record above. It was wrong about real people often enough that the error message had acquired a specific apology to Safari users.
What guards the sign-in form now is entirely ours:
- the hidden field, which was doing the work already
- a signed timestamp on the form, so a submission arriving faster than a person could read the labels is refused, and a script posting straight at the login endpoint without loading the page has no stamp at all
- the existing rate limit
- and the piece reCAPTCHA never provided: a failed login now counts towards an address being blocked at the firewall. Password guessing gets dropped rather than scored.
Registration keeps email verification, and an existing tenant still cannot self-register, which remains invite-only.
What still leaves
Stripe, for payment. That is the list.