Free Website Security Audit — Headers, TLS, DNS & Email

Why we built it, and what it checks

The job was to find anything on the whole server that shouldn't be there, hidden back doors, code that could be hijacked, passwords or keys left in the open, and settings left dangerously loose. A public tool checks a site from the outside, the way a visitor's browser sees it; that is blind to what happens behind the scenes on the machine itself, the files on disk, which programs run and with how much power, and how the server is logged into. So we built one program to walk the entire server and check it all in one pass. Rather than settle for the obvious, we kept adding to its checklist until it covered 25 separate kinds of problem across the code, the running programs, the secrets, the components and the wider machine.

The first run, and a fair challenge

It finished quickly and returned a long list. The speed was rightly questioned, a real check of a whole server shouldn't finish in a blink. Two things were true: reading through a folder of text files genuinely is fast, so that alone wasn't suspicious; but the scanner had only looked inside one folder, because of a mix-up between where we'd dropped the script and what we actually wanted it to scan. Pointed properly at the top of every site on the machine, it produced the real picture: 253 possible issues.

Sorting real problems from false alarms

The 253 split three ways, genuine problems, the scanner being over-cautious, and things already done right. What follows is every fix that came out of that: first the real changes made to the server, then the corrections to the scanner itself. Those tool corrections are the "generation issues" this page is named for, building an honest checker meant first fixing the checker.

The real server fixes

1 · Sensitive settings files locked down. Several files holding the site's most sensitive secrets, database passwords and private keys, were readable by any account on the machine, not just the website itself. We tightened access on every one so only the owner can read them, then checked each: the display flipped from "owner, group and others can read" to "owner only."

2 · Backups removed from public folders. Backup copies of pages and of the database were sitting inside folders anyone can reach by guessing the address. We listed every one first so it could be eyeballed, deleted exactly those, then re-ran the listing to confirm it came back empty. Nothing outside those folders and nothing that wasn't a backup was touched.

3 · Duplicate all-powerful programs removed. Four programs were running with full administrator power. Before removing anything we checked which programs were actually answering live visitor traffic, by matching each to the exact network "door" it was listening on. The site's real copies were already running safely under a restricted account and held the live doors; the powerful duplicates held none, dead leftovers. Only then did we remove the two duplicates, lock in the change so they wouldn't return after a restart, and confirm the live site still served correctly.

Fixing the scanner itself, the generation issues

4 · Database wrongly reported as open to the internet. The scanner flagged the database as reachable from the whole internet. It wasn't, it was correctly locked to the machine only. The scanner had been fooled by a column in the output that always shows a wildcard "any address" value regardless of the real setting. We fixed it to read only the column that actually states the bind address.

5 · Settings-file check too strict. The check insisted on one exact permission value, which meant it would have wrongly complained about an even stricter, safer setting. We changed it to simply ask "can anyone other than the owner read this?" and flag only if the answer is yes.

6 · Encryption result not explained. The encryption check ran correctly but printed the raw technical result without saying what it meant, so a genuinely good outcome (an outdated, insecure protocol being refused) read like an unexplained error. We made it interpret the result and label it clearly as a pass.

7 · Folder-listing check tripping on a switched-off line. The check for "can people browse folder contents" would trigger on a configuration line that had been commented out (switched off) rather than one actually active. We taught it to ignore switched-off lines.

8 · Telling a real use of a risky feature from writing about it. The scanner mistook a blog article that was about a risky programming feature for code actually using it. We fixed the detection to tell the two apart, and caught our own mistake doing so, because the first attempt wrongly cleared a genuine use that sat tucked inside a line with other code around it. We fixed that and re-tested against a set of real examples until every one was judged correctly.

9 · Ignoring third-party code we don't own. A lot of noise came from the internal workings of well-known third-party libraries and a bundled chat app, code we neither wrote nor can change. We taught the scanner to skip genuine third-party and machine-generated bundles for the code checks, which is the correct call (unlike skipping our own files, which would be dodging).

10 · Tightening what counts as a "leaked password". The scanner was matching ordinary words like "secret" or "token" buried inside compressed third-party code as if they were real credentials. We tightened it to only flag something with the actual shape of a credential, and to ignore values that are correctly pulled from a safe settings source rather than written into the code.

11 · Ranking backup files by real danger. Not every stray backup is equally risky. We changed the check so backups sitting in a public folder, or ones that look like they contain settings/credentials, are flagged as high priority, while the rest are noted as lower, so the truly dangerous ones stand out instead of drowning in the list.

The result

12 · The count coming down. As the real fixes and the accuracy corrections went in, the number of findings fell from 253 to about 197 once the biggest false-alarm category was fixed, and lower again in later parts as switched-off sites were skipped and scattered backups tidied away, eventually a handful that are nothing but our own deliberate backup archives, kept in a private folder the internet can't reach. The point was never only to fix the real issues, but to end up with a checker accurate enough to trust, so a real problem can never hide inside a pile of false alarms.

Three threads that began in this sweep get their own full sections: turning off the powerful account's password login and the file-access snag (Part 2); a real, brief outage while making restarts safe (Part 3); and a genuine weakness fixed in an admin-only tool (Part 4).

Key points

• The test runs on the machine itself, so it sees what no online scanner can, actual files, permissions, and which programs run with what power.
• Its first run raised 253 flags; most were false alarms from third-party code, not real problems.
• The genuine fixes were few but real: a world-readable secrets file, a public backup file, and a duplicate all-powerful program.
• Just as much work went into fixing the checker itself so it stopped crying wolf, ending at 7–8 accurate findings.
• The goal was a checker accurate enough to trust, so a real problem can never hide inside a pile of noise.

Questions & answers

Why not just use an online scanner? An online scanner only ever sees your site the way an outside visitor's browser does, the pages, the headers, the TLS certificate. It has no way to see file permissions, hidden backup files sitting in folders, or which background programs are running and with how much power, because none of that is exposed over HTTP. Those invisible layers are exactly where the real risks in this audit turned out to be. That's why the main checks were run by a script on the machine itself, which can read the actual filesystem and process list. The online scanner and the on-machine script answer two different questions, and you need both.

253 problems sounds alarming, was it? No, the headline number was mostly noise, not danger. The large majority of those findings came from other people's code bundled into the site: plugins, third-party libraries, and minified vendor files that aren't yours to fix and aren't actually risky in context. The genuinely fixable problems were a small handful once that noise was stripped out. Rather than leave you to mentally filter 253 items every time, we spent the effort making the checker itself more accurate so the count reflects real risk. A tool that cries wolf 250 times is a tool people stop reading.

Why fix the checker instead of just reading past the false alarms? Because a checker you have to mentally filter is a checker that will eventually let a real problem slip past unnoticed. Every false alarm you learn to ignore trains you to skim, and the one genuine issue buried in the noise gets skimmed too. Accuracy isn't a nice-to-have here, it's the entire point of having the tool. So the fix was to teach the checker to recognise vendor code and safe-by-context patterns and stop counting them, without hiding anything genuinely risky. The result is a shorter list you can actually trust.

Is anything still flagged? Yes, but only things we put there on purpose. A few backup archives we created during the cleanup are still flagged, and they're kept in a private folder that the internet can't reach. They show up because the checker is doing its job and reporting every archive it finds, not because they're a problem. They're expected, known about, and safe where they sit. Leaving them flagged-but-explained is more honest than suppressing them and pretending the folder is empty.

What the scan flagged, and why it was the most urgent thing on the list

The server audit reported that the most powerful account on the machine, the "root" account, which can do absolutely anything, read or change any file, on any of the sites hosted there, could be logged into with just a password. On any server that is the single most attractive target there is, and it is worth being clear about why. A password is a secret that only has to be discovered once: it can be guessed by automated attacks that try thousands of combinations a second against an exposed login, around the clock, forever; it can be leaked in a breach of some completely unrelated website where the same password happened to be reused; or it can simply be worked out from information about the owner. And because this particular account can touch every other site on the box, not just its own, a single successful guess would not compromise one website, it would compromise all of them at once. That is why closing this door mattered more than almost anything else the audit found.

The plan, and why we deliberately did not just switch the login off

There were two moves to make, and the order of them mattered. First, create a new, limited administrator account for everyday work, so that routine tasks stop running with unlimited power by default, the principle being that you should only hold full power in your hands at the exact moment you need it, not all the time. Second, change the powerful account itself from "a password will let you in" to "only a cryptographic key will let you in".

The tempting shortcut would have been to simply turn the powerful account's remote login fully off. We deliberately did not do that, and the reason is important: the file-management tool used to move files on and off the server (FileZilla) reaches the machine through that same account. Switching its login fully off would not just close the door to attackers, it would lock out a tool actually in daily use. So the real target was the precise middle setting: refuse all passwords, but still accept a valid key. That keeps the legitimate tool working for whoever physically holds the key, while removing the password that anyone in the world could try to guess.

1 · The limited account, created, and proven before anything else was touched

We created the new limited account and gave it the ability to carry out full-power administrative tasks when it explicitly asks to, the normal, safer pattern where you work as an ordinary user and elevate to full power only for the specific command that needs it. Then, before touching the powerful account's login settings at all, we proved the new account actually worked: we had it perform a task that requires full power and confirmed it succeeded. This proof was the safety net for everything that followed. The single most dangerous moment in this whole job is the point where you change the login rules and restart the login service, if you have made a mistake, that is the moment it locks you out with no way back in. By confirming the new way in worked first, we made sure that even if the change to the powerful account went wrong, there was still a proven, working route onto the server.

2 · Turning off the password login, and the lockout it immediately caused

We switched off password login for the powerful account and restarted the login service to apply the change. Almost at once a real, unplanned problem surfaced: the file-management tool stopped connecting. The reason is a piece of plumbing that is easy to miss, the file tool does not use its own separate channel; it rides on the very same secure login system we had just tightened (file transfer here is a feature built on top of the secure shell, not a thing beside it). It had quietly been authenticating as the powerful account using that account's password. The moment we forbade passwords for that account, the file tool lost its way in along with the attackers we were trying to keep out. This was not a hypothetical side effect noticed in review, it was an immediate loss of a tool in active use, and it had to be solved before we could go any further, which is exactly what the next steps did.

3 · Setting up the key-based login in its place

We generated a cryptographic key pair on the local computer. A key pair is two matching halves: a private half, which is a secret file that never leaves your own machine and stands in for the password, and a public half, which is not secret and is placed on the server. The server, holding the public half, will only let in someone who can prove they hold the matching private half, and because the private half never travels across the network the way a typed password does, there is nothing for an eavesdropper to capture and nothing for a guessing attack to grind against. We placed the public half on the server for the powerful account and set that account to the middle position described earlier: no passwords accepted, but a valid key accepted. That single change restores the file tool's way in, but now only for the person physically holding the private key.

4 · The fiddly part, getting the key into the right format, and the real mistakes made doing it

The file-management tool does not accept the key in the standard format it was created in; it needs the key converted into its own particular format first. This conversion is where genuine trial and error happened, and it is worth being candid about rather than presenting it as smooth. The conversion tool has a "Save public key" button and a "Save private key" button sitting right next to each other, and the wrong one was clicked more than once, which produced a file that looked for all the world like the converted private key the tool needed, but actually contained the public half, which is useless for logging in. The confusion was made considerably worse by the computer being set to hide file extensions: with the endings hidden, the original private key, its public counterpart, and the converted file all displayed under the same name, giving no visible way to tell three quite different files apart. We caught the mistake by opening the suspect file and simply reading it, it plainly announced itself, in its very first line, as a public key, then switched the computer's setting so that file extensions were visible again, which made the three files distinguishable at a glance, and repeated the export with the correct button. It was a small, human error, but a genuine one, and it is part of the honest record of how this was done.

5 · Confirming the whole thing actually works

We then confirmed the two facts that matter, rather than assuming them. First, that a password login to the powerful account is now refused outright, proving the door we set out to close is genuinely closed. Second, that a login using the key succeeds, proving we did not lock ourselves out in the process. Finally, the file-management tool was pointed at the newly converted key and reconnected cleanly, confirming the tool that broke in step 2 is fully restored on the safer footing.

6 · The one lasting consequence, stated plainly

There is a real, permanent trade-off to be honest about. Because everyday work now runs through the limited account rather than the all-powerful one, that account can only reach the files it has been given permission to reach. In practice this means that trying to browse a different site's folders through the everyday account is now refused, which is exactly correct and safe behaviour, and precisely the isolation we wanted, but it does change the daily routine: for work on other sites you now use either the powerful account's key or that site's own separate login, rather than reaching everything from one all-powerful account. Less convenient, deliberately, in exchange for a great deal less risk. This same trade-off surfaces again later in the audit.

Key points

• The most powerful account on the machine could be reached with just a password, the single most attacked door there is.
• Because that account can touch every site on the server, one guessed password would compromise all of them, not one.
• We didn't switch its login off, that would lock out the file tool that uses it. We set it to refuse passwords but accept a key.
• A limited everyday account was created and proven to work first, so we could never lock ourselves out making the change.
• Turning off the password briefly broke the file tool, because file transfer rides on the same login system, fixed by switching it to the key.

Questions & answers

Why not just turn off the powerful account's remote login completely? Because a file-management tool you use every day connects through that exact account, and turning its remote login off entirely would lock the tool out along with any attacker. The goal was to shut the door on attackers without breaking your own workflow. So instead of disabling the account, passwords were refused while key-based access was kept, an attacker has no password to guess, but your tool still gets in with its key. That's the difference between locking the door and bricking it shut. One keeps you out; the other keeps everyone out.

Why did the file tool suddenly stop working? File transfer runs over the same secure login system as everything else, and your file tool had been getting in using the account's password. The moment password logins were refused, the tool lost its way in, nothing was broken, it simply no longer had valid credentials. Switching it over to use the key instead restored access immediately. It's the same reason a door key stops working the day the lock is changed: expected, and fixed by handing over the new key. No data or settings were lost in the gap.

Why is a key safer than a password? A password is a shared secret, it can be guessed, reused across sites, phished, or leaked in a breach, and it physically travels across the network each time you log in, where it could be intercepted. A key works differently: its secret half never leaves your own computer, and only a matching public half sits on the server. Because the secret never travels, there's nothing to intercept in transit, and because it's long and random, there's nothing practical to guess. That combination is why key-based login is the standard for anything that matters. A password is a secret you send; a key is a secret you keep.

What changed day-to-day? Day-to-day work now runs through a limited account that can only reach the files it's specifically been given, rather than an all-powerful one. Reaching another site's files now requires either the key or that site's own login, instead of one account quietly having access to everything. It's deliberately a little less convenient, an extra step to cross between sites, and that friction is the point. The trade is a small amount of daily convenience for a large reduction in what a single compromised login could touch. Nothing you normally do is blocked; it's just properly scoped.

Why we were looking at this at all

After the earlier clean-up work, removing duplicate all-powerful programs, tightening logins, the sensible next step was to make sure the whole server could survive being switched off and on again. A reboot is meant to bring every website back up automatically, without anyone having to log in and start things by hand. The trouble is that this only actually works if the machine has been told, correctly, which programs to bring back and how. If that instruction is missing or broken, a reboot doesn't warn you, the server simply comes back with the site dead, and stays that way until a human notices and intervenes. We wanted to confirm the automatic recovery genuinely worked before ever triggering a real reboot, precisely so we would never find out the hard way.

What we found, a safety net that wasn't actually holding anything

On the server there is a supervisor system whose entire job is to start the website's background programs and keep them running, including bringing them back after a reboot. When we inspected it, we found something quietly wrong: the part of it responsible for the main site was switched off and doing nothing, yet it was marked as enabled, so at a glance everything looked fine. The website's programs were in fact still running, but only because a copy of the supervisor had been started by hand in an earlier session and was holding them up. Nothing was actually relying on the automatic system that is supposed to take over after a reboot.

The plain-English version: the safety net existed on paper and looked to be in place, but nothing was resting on it. Everything was working at that moment purely because of a hand-started process that would not survive a restart. Reboot the machine in that state and the hand-started copy vanishes, the automatic system fails to take over, and the site does not come back. That is exactly the trap we were trying to find before it sprang.

1 · Saving the current state first

Before changing anything, we did the cautious thing: we saved an up-to-date snapshot of exactly which programs were currently running and how. This matters because the automatic recovery system restores from a saved list, and if that saved list is stale or empty, "recovery" brings back the wrong things or nothing at all. Capturing the correct current state first meant that whatever we did next, the system had an accurate record to rebuild from.

2 · Testing the recovery, and why it didn't work

Rather than assume the automatic system would work once switched on, we tested it in a controlled way, deliberately, while we were watching, not by gambling on a real reboot. It failed. The system reported that it could not complete its start-up steps and fell into a loop, trying and failing over and over. Digging into the cause, we found a specific setting that instructed it to look for a particular little "status file" as proof that start-up had succeeded, but the software in question never actually creates that file. So the check could never pass: every start-up looked like a failure to the supervisor, even when the programs themselves were fine, which is what drove the endless retry loop.

3 · The fix attempt that caused the outage

This is the honest part, reported in full rather than smoothed over. Our first attempt at a fix backfired and briefly took the live site offline. The logic seemed sound: remove the faulty "look for a status file that never exists" setting, then reload the supervisor so the change takes effect. But reloading it did something we had not anticipated. Buried in the supervisor's configuration was a separate instruction that said, in effect, "whenever you stop, for any reason at all, shut down every one of the website's programs as you go." A reload counts as a stop-and-start. So the instant we reloaded to apply our harmless-looking fix, that shutdown instruction fired, and it took down all of the site's running programs with it. Every part of the live website went offline as a direct, immediate result of our change. This was a genuine outage that we caused, not a near-miss, and it is part of the honest record.

4 · Getting back online

We brought everything back within a few minutes using the supervisor's own built-in "restore whatever was running" command, feeding it the accurate snapshot we had saved in step 1, which is exactly why saving that state first mattered. There was one awkward wrinkle worth explaining. For security, the website's own account is deliberately configured so that it cannot open a normal interactive command session, a sensible hardening measure that stops that account being used as a way in. But that same restriction blocks the straightforward way of starting the programs back up under that account. So the restore had to be run through a specific, explicit workaround that launches the recovery correctly as that locked-down account despite the restriction. Once that went through, all of the site's programs were back and the site was fully restored.

5 · Finding and removing the real cause

With the site safe again, we went back and traced the true culprit properly, rather than papering over it. The real problem was never the missing "status file" setting on its own, it was that buried "shut everything down on any stop" instruction. That kind of instruction has a legitimate use for a genuine, final shutdown of the machine, but here it was written to fire on every stop and restart, including entirely routine ones. That is what turned an ordinary reload into a site-wide outage, and it would have done the same on any future maintenance restart too. So we removed that instruction outright, eliminating the actual mechanism of the outage rather than just avoiding the one action that had triggered it.

6 · Testing a real restart, no interruption this time

Having removed the real cause, we did not simply declare it fixed, we proved it. We deliberately triggered a genuine restart of the supervisor, the very kind of action that had caused the outage the first time. This time every one of the website's programs stayed running straight through it, with no gap and no interruption at all. That is the difference between a fix that was merely worked around and one that is genuinely gone: the same action that broke the site before now runs cleanly.

7 · Outcome

The fault is permanently fixed and tested. Two real gains came out of it: the automatic recovery system now starts cleanly and will bring the site back by itself after a reboot instead of leaving it dead, and the specific hidden instruction that caused the outage is gone, so routine maintenance restarts can no longer take the site down. The brief downtime along the way was real, was caused by our own first attempt, and was resolved within minutes, and the end state is meaningfully safer than where we started, which is the whole point of having found this before a real reboot did.

Key points

• A boot service can be enabled but dead, it looks fine while nothing actually relies on it.
• The live programs were being held up only by a hand-started copy that would not survive a reboot.
• A hidden "shut everything down on any stop" instruction turned a routine reload into a full outage.
• Recovery needed a workaround because the site's account is deliberately barred from opening a normal session.
• Removing that instruction and then testing a real restart made the fix genuine, not merely worked around.

Questions & answers

Isn't "enabled" the same as "running"? No, they're two separate states, and both have to be true for the safety net to actually hold. 'Enabled' only means a service is set to start automatically at the next boot; it says nothing about whether it's running right now. A service can be enabled yet switched off and doing nothing at this moment, or running yet not enabled and therefore gone after a reboot. The check confirmed both: set to start at boot, and actually up. Assuming one implies the other is exactly how a reboot surprise happens.

Why did simply reloading take the site down? The supervisor that manages the site's programs had a hidden instruction to shut down every program whenever it itself stops. A reload counts as a stop-then-start, so that shutdown instruction fired and took the live programs down with it. Nobody expected a routine reload to be destructive, which is exactly why it was dangerous. The instruction belonged only to a genuine, deliberate shutdown, not to a reload. Removing it was the real fix.

Why not just restart normally to bring it back? The site's account is deliberately locked down so it can't open an ordinary interactive session, a security measure that also happens to block the normal restart path. So bringing the programs back couldn't use the usual command; it had to go through a specific workaround that forces a working environment for that locked account. That's why recovery looked unusual rather than a simple 'start it again'. The lockdown is a feature, not a fault, it just meant recovery needed the right technique. Once used, everything came back.

Is the site reboot-safe now? Yes. The dangerous instruction that tore everything down on a stop has been removed, so the trigger no longer exists. More importantly, we didn't just assume it was fixed, we ran a real restart, the exact action that caused the original outage, and watched every program stay up. Same trigger, no teardown, proven rather than hoped. That's the difference between a fix and a fix you can trust.

Why this one mattered more than its size suggests

Most of what the server scan turned up was housekeeping, permissions to tighten, stray files to clear. This one was different in kind: an actual way that malicious code could, under the wrong circumstances, be made to run. It was small, it was narrow, and it sat inside a tool only administrators can reach, but "small and narrow" is precisely the sort of hole that gets left alone until the day it doesn't, so it was worth understanding fully and closing properly rather than waving through.

What the scan flagged

Inside an admin-only diagnostic tool, the scanner found that some text, error messages pulled straight from the server's own internal logs, was being placed onto the page without being "cleaned" first. Cleaning, here, means neutralising the handful of characters that a web browser would otherwise treat as instructions rather than as ordinary text to display. The telling detail: a very similar piece of information sitting right next to it, on the very same page, was being cleaned correctly. So this wasn't a tool with no idea about safety, it was a single inconsistent spot, one place doing it right and one place, a few lines away, forgetting to.

1 · Reading the actual code, why it was a real risk, not a theoretical one

When text is dropped onto a page without cleaning, and that text ever happens to contain something shaped like a web instruction, the browser can be fooled into carrying it out instead of simply showing it. Here, two values were going onto the page unclean, the name of a running program and an error message, and both were coming from the server's internal error logs. Those logs are not something an ordinary visitor can freely write into, which is what kept the risk narrow. But narrow is not the same as none: internal logs routinely capture fragments of text that originally came from less trusted places, and once such a fragment lands on the page unclean, the browser has no way of knowing it was ever meant to be plain text.

2 · Why it mattered, who would actually be hit

The concrete danger runs like this. If something unusual, or something deliberately crafted by an attacker, ever found its way into one of those logged error messages, then the next time an administrator opened this diagnostic page, that crafted content could execute inside their browser, carrying all the access and privilege an administrator has. It is the classic shape of a quiet, high-value hole: it doesn't threaten ordinary visitors, it threatens the one person whose account can change everything. That is exactly the kind worth closing on sight, especially when the fix costs almost nothing.

3 · The fix, reusing what was already proven

We deliberately did not invent a new safety mechanism. The same page was already cleaning a neighbouring piece of data correctly, so we applied that identical, already-working method to the two spots that had been missed. After the change, the risky characters in a program name or an error message are converted into their harmless "just display this literally" form, so nothing arriving from a log can ever be mistaken by the browser for an instruction. Matching the existing approach, rather than bolting on a different one, also means the code stays consistent and easy for a future reader to understand.

4 · How we applied it carefully

We were deliberately cautious about the mechanics of the change, not just its content. The edit was made with a method that only alters the file if it finds the exact text it expects, character for character, and does nothing at all if anything fails to match, which removes any chance of a half-applied or corrupted edit silently breaking the tool. We also saved a backup copy of the file before touching it, so the previous version could be restored instantly if anything looked wrong afterwards.

5 · Outcome

Found and fixed the same day, and confirmed correct immediately. Because this is a file the browser loads and runs directly, rather than something running on the server, no restart of any service was needed; the corrected version simply takes effect the next time the page is opened. The inconsistency is gone: both spots now clean their text the same way the neighbouring code always did, and there is no longer a path by which logged text can reach the page as a live instruction.

Key points

• The one finding in the whole sweep that was a genuine way for malicious code to run, not just housekeeping.
• Two pieces of log text were placed on an admin-only page without being cleaned, while identical neighbouring text was cleaned.
• The risk is narrow (admin-only, log-sourced) but real: crafted text in a log could run in an administrator's browser.
• Fixed by reusing the cleaning method already working a few lines away, no new mechanism invented.
• Applied with an exact-match edit and a backup; it's a browser-loaded file, so no restart was needed.

Questions & answers

If only admins can see this page, why bother fixing it? Because an administrator account is the highest-value target on the whole system, it can change anything, so anything that can influence what an admin sees is worth locking down. On top of that, text that starts out from an untrusted source can quietly end up captured in logs, and those logs get viewed later in exactly that admin context. So the risk isn't hypothetical even on an admin-only page. The fix was tiny and the potential impact large, which is precisely the combination you close rather than accept. 'Only admins see it' lowers the odds, not the stakes.

What does "cleaning" the text actually do? Cleaning converts the handful of characters a browser treats as instructions, the ones that start and end tags, into their harmless 'display this literally' form. After that, a piece of text like an error message can only ever be shown on screen, never interpreted as code to run. It doesn't change what the message says; it changes whether the browser can be tricked by it. That single conversion is what turns a potential injection point into plain, safe output. It's the standard defence for any text that reaches a page.

Why reuse the existing method instead of writing a new one? The same page already cleaned a neighbouring value correctly, so a proven, working method was sitting right there. Reusing it keeps the code consistent, avoids introducing a new and untested approach, and means the next person reading the file sees one pattern rather than two. New code is where new bugs come from; reused, already-correct code isn't. It also made the change smaller and easier to review. When a safe method already exists a few lines away, copying it is the disciplined choice.

Did the site need to be restarted? No, the change was to a file the browser loads directly on the client side, not to a running server program. That means there's nothing to restart; the corrected version simply takes effect the next time someone opens the page. No downtime, no deploy step, no service bounce. It's one of the quieter kinds of fix. The moment the file is in place, the next page load is already using it.

What the scanner flagged, and why we didn't just accept it

Because the server test looks at every website hosted on the machine, not only the main one, it swept up some old, risky-looking code and flagged it. The easy thing would have been to treat that as one more problem to fix. But a flag is a starting point, not a verdict: the honest step is to find out what the code actually belongs to and whether it is genuinely live, rather than reacting to the label. On investigation, the code turned out not to belong to the main business at all. It was part of a completely separate website that the owner had deliberately suspended roughly a year earlier, switched off on purpose, not abandoned by accident.

1 · Confirming it really was suspended, two independent checks

We did not take "it looks suspended" on trust; we confirmed it two different ways so a single misleading signal couldn't fool us. First, we asked the hosting control panel directly what state it considered the site to be in, and it reported the site as suspended by the administrator, an authoritative answer from the system that actually manages the hosting, not a guess. Second, we tried to connect to the domain the way any visitor's browser would, and it did not respond at all, no page, no redirect, nothing. Two independent facts pointing the same way: the control panel says off, and the live internet agrees it is unreachable.

2 · The spammy content in search results, chased down, not hand-waved

A general web search for that old domain did turn up some unpleasant, spammy-looking content, which is exactly the sort of thing worth taking seriously rather than dismissing. So we chased it down properly. It proved to be leftover cached content, old copies held by search engines from before the site was switched off, not anything currently being served. Since the site itself no longer responds at all, there is nothing live behind those stale search entries; they are echoes of a site that is already gone, and they fade from search results over time on their own.

3 · A real decision, should a dead site even be in the scan?

This raised a genuine judgement call worth being open about. The tempting move was to simply tell the scanner to ignore that site entirely and be done with it. We actually tried that, and then deliberately reversed it. The reasoning matters: this is a whole-server security test, and the whole point of that is that it sees everything on the machine. Quietly dropping a site because it happens to look unrelated is exactly the kind of silent assumption that lets a real problem hide. If the same test were run for anyone else, it shouldn't secretly skip sites based on a guess about what's "in scope". So the rule we settled on is the honest one: every site stays visible in the scan, but a suspended site's findings are clearly labelled as suspended and set aside from the live-risk count, visible, accounted for, but not mixed in with problems that can actually affect someone today. Nothing is hidden; it is just correctly categorised.

4 · The fiddly part, getting the right command to ask about suspension

Teaching the scanner to recognise a suspended site meant asking the hosting control panel, in code, which sites are suspended, and that was not smooth first time, which is worth recording honestly given this report is partly about exactly these generation issues. The obvious-looking command to list suspended sites returned nothing at all, not because there were none, but because that particular version of the control panel's tool didn't accept that phrasing. Rather than guess at variations, we asked the tool itself for its real list of accepted options, found the correct form, and then had it report each site's status one by one. Only once we could see the real, confirmed status for every site did we build that exact query into the scanner. It was a small detour, but a real one, and doing it by checking rather than guessing is what stopped a wrong assumption being baked into the tool.

5 · Fixing the real problem, the scanner's blind spot

The genuine lesson was never about that one old site; it was that the scanner had no concept of a site being suspended at all. It treated dead code on a switched-off site exactly as seriously as live code on a running one, which is misleading twice over, it inflates the problem count with issues that cannot affect anyone, and in doing so it buries the findings that actually matter under noise. So we built in the check we'd just worked out: at the start of every run, the scanner now asks the control panel which sites are officially suspended and automatically sets those aside, replacing a pile of per-file flags with a single clear line noting the site was skipped and why.

6 · Outcome

This particular false alarm is resolved, and, more importantly, it can't recur. The scanner now recognises a suspended site for what it is and sets it aside automatically, for this site and for any site suspended in future, while still keeping it visible in the report rather than silently dropping it. The result is a report that's both cleaner and more honest: the live-risk count reflects real, reachable problems, and dead code on unreachable sites is accounted for separately instead of masquerading as urgent.

Key points

• The server test checks every site on the machine, so it flagged old code on a completely separate website.
• That site had been deliberately switched off by its owner about a year earlier, not live, not reachable.
• We confirmed it two independent ways: the hosting control panel says suspended, and the domain doesn't respond at all.
• Spammy content in search results was old leftover cache from before shutdown, not anything live.
• We kept the site visible in the scan but set aside from the live-risk count, never silently dropped, and taught the scanner to do this automatically.

Questions & answers

Why not just fix the risky-looking code? Because that code lives on a website that was deliberately switched off and can't be reached by anyone on the internet. Fixing code on a dead, unreachable site achieves nothing real, there's no live path for anyone to exploit it. The actual problem wasn't the code; it was that the scanner was counting a suspended site as if it were live and adding to the risk total. So the fix belonged in the scanner's understanding of site status, not in the dead code. Treating the symptom would have wasted effort on something already harmless.

Why not just tell the scanner to ignore that site completely? Because a whole-server audit that quietly skips sites is exactly how a genuine problem slips through unnoticed one day. If a site can vanish from the scan by assumption, so can a real risk hiding on it. So instead of dropping the suspended site, it stays visible in the report and is simply set aside from the live-risk count, clearly labelled as suspended. You get the honesty of seeing every site, without a dead one inflating the numbers. Excluding from the tally isn't the same as hiding from view.

Should the spammy search results worry you? No, those results are old copies held by search engines from before the site was shut down, not anything being served now. The live site returns nothing, so there's no active content behind those listings for anyone to reach. Cached entries like these naturally drop out of search over time as engines re-crawl and find the pages gone. There's nothing to clean up at the source because the source is already off. It looks alarming in a search box but it's stale, not live.

Why check the control panel and try loading the site? Because two independent checks are stronger than either one alone. The hosting control panel confirms the site was suspended deliberately, that's the authoritative record of intent. Trying to actually load the domain confirms it really is unreachable in the real world, not just marked that way in a database. One check tells you what should be true; the other tells you what is true. Agreeing on both is how you rule out a stale or mistaken status.

What we found, and why a running program you're not using is a risk

The server test turned up something nobody was expecting: a large team-chat application, around 605 megabytes of software, still actively running in the background on one of the hosted sites. The oddity is that the actual live website for that domain is just two simple static pages that have nothing whatsoever to do with a chat app. So here was a substantial, complex piece of software quietly running and consuming memory, that the live site did not need and nobody was using, almost certainly the leftovers of something set up once and long forgotten.

That matters for security, not just tidiness, and it's worth being clear about why. Every program left running is part of what an attacker could try to reach, the more software you have running, the more separate doors there are into the machine, and a large chat application you're not even using is a great deal of extra door for zero benefit. Worse, software that sits unused tends to go unpatched, because nobody is watching it or updating it; over months and years that quietly turns it into one of the most attractive ways in, since it accumulates known weaknesses that no-one is fixing. The safest possible state for something you genuinely don't use is switched off, and then gone entirely.

1 · Confirming it genuinely wasn't part of the live site

Before removing anything, we made sure the chat app really was disconnected from the live website and not quietly serving some part of it behind the scenes. We checked how the site's traffic is actually routed, where a visitor's request goes when they load the page, and confirmed it goes only to those two simple static pages. Nothing was ever being handed off to the chat application. It was running, but running in isolation, wired into nothing that a real visitor ever touches. That confirmation is what made it safe to remove: we weren't guessing it was unused, we had checked the actual traffic path and seen that it was.

2 · Switching it off, safely, and for good

We switched the chat application off completely, and, just as importantly, made sure it could not automatically turn itself back on later, including after a server reboot. This is a distinction that's easy to get wrong: stopping something without also stopping it from restarting is only half a fix, because a program set to auto-start would simply come back to life the next time the machine restarted, quietly undoing the work. So we did both, stopped it now, and removed its permission to start itself in future, then confirmed directly that it was genuinely marked as "will not start on its own" rather than assuming the command had taken.

3 · Backing it up before deleting a single file

Even though nothing was using it, we did not delete 605 megabytes of software on the assumption that it was worthless, that is exactly the kind of assumption that occasionally turns out to be expensively wrong. Instead we made a full, compressed backup of the entire installation first, then verified that backup genuinely contained everything, confirming it held the complete set of files, correctly and readably, rather than trusting that the backup command had simply worked. Only once we could see for ourselves that the archive was complete and sound did we delete the original folder. The backup was placed in a private location that is not reachable from the public internet, so it isn't itself an exposure. If it ever turns out something in there was wanted after all, it can be restored.

4 · Confirming the real site was never affected

Throughout the stop, the backup, and the deletion, we repeatedly confirmed the one thing that actually matters: that the live website, those two simple pages, stayed completely intact and reachable. It did, at every step, not just once at the end. The removal touched only the unused chat software, and nothing the public ever sees was altered.

5 · Clearing up the leftover reference the removal left behind

Removing the files was not quite the whole job, and this is the sort of detail that's easy to miss. The system that had been keeping the chat app running still held a leftover reference to it, a pointer to a service that no longer existed anywhere on disk. Left in place, that kind of dangling reference is untidy at best and, at worst, causes confusing errors later when something tries to act on a service that's gone. So we cleaned up that stale reference too, so the system's own record matches reality: the service isn't just stopped and deleted, it's no longer referred to at all.

6 · A real bug we caught in our own scanner along the way

This is the honest, on-theme part. While doing this, we found that our own scanner's check for "is this program actually switched off?" had a genuine flaw. To decide which program was which, it had been reading a field that can contain several different path-like pieces of information jumbled together, and because of that, it briefly matched a completely unrelated site instead of the chat application we were actually checking. In plain terms, the tool could have told us the wrong thing about whether something was really off, a serious kind of error in a tool whose whole job is to report accurately. We traced exactly why it happened, and fixed it to read instead from a single, unambiguous field that always points at the one right answer, so the "is it off?" check cannot be misled that way again.

7 · Outcome

The unused chat application is stopped, prevented from restarting, backed up, verified, deleted, and its leftover system reference cleared, 605 megabytes of unnecessary running software and attack surface gone, with the live site untouched throughout. And the scanner itself is more trustworthy than before, because a real flaw in how it judged "switched off or not" was found and corrected in the process.

Key points

• A large team-chat app (about 605MB) was running in the background on a domain whose real site is just two static pages.
• Unused running software is extra attack surface that tends to go unpatched, a growing liability for zero benefit.
• We confirmed it wasn't part of the live site, then switched it off and stopped it restarting, and checked that took.
• We made a verified backup in a non-public location before deleting, and confirmed the live pages stayed intact throughout.
• We cleared the leftover system reference the removal left behind, and fixed a real flaw in our scanner's "is it off?" check.

Questions & answers

If it wasn't doing any harm, why remove it? Because unused software is still a way in, even while it sits idle. It can be exploited if a flaw is found, or restarted by accident or attacker, and because nobody's actually using it, nobody keeps it patched, so its risk quietly grows over time. Removing it takes away that whole class of risk in exchange for something that was providing no benefit. Idle isn't the same as safe. The safest component is the one that isn't installed at all.

Why not just switch it off and leave the files there? Because switched-off software is still installed code that can be restarted or exploited if a vulnerability turns up in it. 'Stopped' only changes its current state, not its presence on disk. The genuinely safe state is backed-up and removed, so there's nothing left to restart and nothing left to find a flaw in. Keeping a checked backup first means nothing is lost if it's ever wanted again. Off is temporary; gone is permanent.

Why bother backing up something you're deleting? Because deleting on the assumption that something is worthless is exactly how things get lost for good. A checked backup, kept out of public reach, means that if anyone ever turns out to need something from it, it can be brought back. It costs almost nothing to keep and removes the only real downside of deletion, irreversibility. So the removal is safe precisely because it isn't actually irreversible. Delete confidently only when you've made undo possible.

Was the live website ever at risk during this? No, the two real, live pages were confirmed intact at every step of the work. The removal only ever touched the unused chat software, which nothing depended on. Checking the live pages before, during and after meant there was no moment where a visitor would have seen anything wrong. The change was isolated to the thing being removed. Careful scoping is why a cleanup didn't become an outage.

What we found, and why "full-power and unused" is the worst combination

On a second website belonging to the same owner, the server test found two background programs running with full administrator-level power, the highest level of access on the machine. That level of power is meant to be held only by things that genuinely need it, and held as briefly as possible, because of what it can reach. A program with full power isn't limited to its own website's files; it can, in principle, touch every site and every account on the whole server. So if one of these programs ever had a flaw, or were ever compromised, the damage wouldn't be contained to that one site, it could spread sideways to every other site sharing the machine. That "reaches everything" quality is exactly why full-power programs are the ones you most want to be sure are both necessary and watched.

And these two were neither. They were running with the maximum possible power, and, as we went on to confirm, doing nothing the live website actually needed. Full power plus no purpose is the worst of both worlds: all of the risk, none of the benefit. It's the kind of thing that tends to accumulate quietly over time: a program set up for some earlier purpose, never switched off when that purpose passed, still running months or years later with power nobody remembers granting it.

1 · Tracing how the site is really served, before assuming anything

The critical question was whether these two programs were secretly doing something important, because switching off something the site quietly depends on would break it. So rather than assume, we traced the actual path a visitor's request takes, step by step, from the moment it arrives to the moment a page is sent back. We confirmed two things in turn. First, where the site's files actually live and are served from: its content is delivered directly from a specific folder of finished files by the ordinary web-server software, not generated on the fly by either of the two programs. Second, that the front door of the server, the part that first receives every incoming request, hands those requests straight to that ordinary file-serving software, and not to either of the two full-power programs. At no point in that real path is either program involved.

2 · The thorough version of that check, not just the obvious route

It would have been easy to check only the main rule, "where do ordinary page requests go?", see that it doesn't touch these programs, and stop there. But that could miss a subtler arrangement, where most of a site is served normally while certain specific addresses (say, anything under a particular sub-path) are quietly routed to a background program. So we deliberately looked for that too: we searched the server's routing rules specifically for any instruction, on any path, that would send traffic to either of these two programs. There were none. Not the main route, and not any side route either, nothing anywhere pointed at them.

3 · Why the absence of a rule was strong evidence, not just an empty result

This is the part that turned "we found nothing" into real confidence rather than a shrug. On this same owner's main site, background programs genuinely are used, and there, the server's routing rules contain exactly the kind of instruction that sends specific traffic to a background program, because that site really depends on one. So we already knew precisely what a "this program is genuinely needed" rule looks like when it exists. Finding that this second site had no such rule anywhere wasn't an ambiguous blank; it was the confident absence of the one specific thing that would have to be present if these programs mattered. We weren't reading nothing into silence, we were noting that a signature we know well, and would expect if they were needed, simply wasn't there.

4 · Switching them off, stopped, not deleted, and made to stick

We switched both programs off. We deliberately chose to stop them rather than delete them outright, stopping removes the running risk immediately while keeping the option to bring them back easily if some need for them ever emerges, which is the more cautious, reversible choice for something that isn't actively harming anything the moment it's stopped. We then made sure that "off" state would survive a server restart, so they wouldn't quietly start themselves up again after the next reboot and undo the fix. Saving that state is what turns a temporary stop into a lasting one.

5 · Reconciling the saved state carefully

There was a subtle point worth being honest about here. The record of "which programs should be running" had last been saved at a moment when these two were still running, so simply trusting the old saved record would have brought them straight back on the next restart. Switching them off is only genuinely permanent once that saved record is re-written to reflect the new reality. So after stopping them, we saved the updated state deliberately, making the new "these two stay off" the version the server will restore from, rather than assuming the stop alone was enough. It's a small step that's easy to skip, and skipping it would have quietly undone the whole fix at the next reboot.

6 · Confirming the real site kept working

With both programs stopped, we checked the actual live website and confirmed it kept loading and working perfectly, exactly as the traffic-path trace predicted it would, since the site never relied on those programs in the first place. That final check is what closed the loop: not just "we think it's safe" but "we stopped them and watched the site carry on unaffected."

7 · Outcome

Both unnecessary, over-powered programs are stopped and kept stopped across restarts, with zero impact on the actual working website. A pair of full-power programs that could have reached every site on the server, for no benefit to anyone, are no longer running, which meaningfully shrinks what an attacker could ever take advantage of on that machine.

Key points

• Two background programs ran with full administrator power on a second site, power that can reach every site on the server.
• Full power plus no purpose is the worst combination: all of the risk, none of the benefit.
• We traced how the site is really served and checked both the main route and any side route, nothing pointed at these programs.
• The absence was strong evidence because the owner's main site does use such a route, so we knew exactly what to look for.
• We stopped (not deleted) both, saved the change so it survives a restart, and confirmed the live site kept working.

Questions & answers

Why does it matter that they had "full power"? Because a full-power program isn't confined to its own site, it can reach every site on the server. That means a single flaw or compromise in one such program could spread to everything on the machine, not just one corner of it. So an unused program running with that much privilege is a large blast radius for zero benefit. That combination is why full-power programs you don't need are worth removing on sight. Least privilege isn't bureaucracy; it's containing the damage when something goes wrong.

How did you know the site didn't need them? Because we traced the actual path a visitor's request takes through the server and read the routing rules directly, both the main route and any side routes. Nothing in that path sent traffic to these programs, so removing them couldn't affect what visitors see. We also know what a genuinely 'needed' rule looks like, because the owner's main site has one to compare against. That's evidence, not assumption. Trace the real traffic, then you can remove with confidence.

Why stop them rather than delete them? Stopping removes the risk straight away and can be undone easily if a need ever appears. It's the more cautious choice for something that isn't harming anything the moment it's off.

Could they come back on after a restart? Not now, we saved the new "off" state so the server restores that, rather than the older record that still had them running.

What the feature was meant to be

Not everything in this write-up is a fix, this part is about a feature that was planned but deliberately not built this time, and it's included for the sake of a complete, honest record rather than to claim credit for work that didn't happen. The idea was a public tool where someone types in something awkward or rude that was said to them, picks a tone, funny, blunt, classy, and so on, and gets back a set of AI-generated comebacks. The results would be stored in a way that search engines and AI assistants could later find and reference, so the feature would also bring in search visibility over time, not just serve the one person using it in the moment.

1 · Doing the homework first, looking at what already exists

Before writing a line of it, we looked at four existing tools that already do something similar. The point of that wasn't to copy them; it was to learn from what they get right and, more importantly, to spot the ways they go wrong so we could design against those from the very start rather than discovering them the hard way after launch. Studying the failure modes of comparable tools is cheaper and safer than making the same mistakes yourself in public.

2 · The genuinely concerning thing we found

One of those existing tools, during our testing, did something that matters a great deal for a feature like this: when a real person's name appeared in the test input, it generated a fabricated, made-up personal insult aimed at that named individual. That is a serious failure mode. There's a clear and important line between helping someone respond wittily to a remark that was actually made to them, and a tool that will invent damaging personal claims about a real, named person on request, the latter is a harassment risk, and it's the kind of thing that turns a light-hearted feature into something genuinely harmful.

3 · The design rule that came out of it

So this shaped a firm design rule for any version we would build, decided up front rather than bolted on later: the tool must always respond to what was actually said, the remark itself, and must never invent personal claims or attacks about a real, named individual. Respond to the words, never target the person. Building that boundary in from the first line of the design, rather than trying to patch it in after something goes wrong, is the difference between a feature that's fun and one that's a liability. Finding this in someone else's tool, before building our own, is exactly what the homework was for.

4 · How it would be controlled and paid for

We also worked out how the feature would be gated, so it isn't relevant to note it wasn't a loose end left unconsidered. It would use the same credit-based system already used elsewhere on the site, the existing mechanism that controls access to the other tools, rather than inventing a new one. Reusing the established pattern keeps the feature consistent with everything else and avoids a whole new set of things that could go wrong.

5 · Why it wasn't built, and why that's the right call

In the end, this feature was deliberately set aside this time in favour of the security work that makes up the rest of this write-up. That was a conscious priority decision, not something forgotten: with real, concrete security issues found on the server, fixing those came first, ahead of building a new public-facing feature. It's an honest reflection of where the effort actually went, and putting known security problems ahead of a nice-to-have new feature is the right order to do things in.

6 · Status

Planned, researched, and scoped, including its most important safety boundary, but not built this session. It's recorded here so the write-up reflects everything that was actually worked on, including the things that were thought through and then, sensibly, deferred.

Key points

• A planned public feature, type in a rude remark, pick a tone, get AI comebacks, recorded here as planned, not built.
• We studied four existing tools first, to learn their mistakes rather than repeat them.
• One of them invented a personal insult about a real named person, a serious harassment failure mode.
• That set a firm rule up front: respond to the remark, never invent claims about a real individual.
• It was deliberately set aside this session so the security work could come first.

Questions & answers

Why look at other tools before building your own? To learn from their mistakes cheaply. Spotting a harmful failure in someone else's tool beforehand is far better than discovering the same failure in your own after it's live.

What was the concerning behaviour you found? One tool, given a real person's name, made up a personal insult aimed at that named person. That's the exact line a feature like this must never cross.

What rule did that lead to? Respond to the remark that was actually made, and never invent personal claims or attacks about a real, named individual, decided before any building began.

Why wasn't it built? Because real security issues on the server took priority. Fixing those came first, ahead of adding a new public feature, a deliberate choice.

Why a tool that always says "fine" is worse than useless

A security-checking tool is only worth anything if it tells the truth even when the truth is uncomfortable. The failure to worry about isn't a tool that's occasionally too harsh, it's one that quietly rubber-stamps everything as fine regardless of what it's actually looking at, because that gives false confidence exactly where it's most dangerous. So before relying on our own public tool for anything, we needed to prove it doesn't do that: that it genuinely inspects a site and reports real, varying results rather than always returning a comfortable pass.

1 · Choosing a fair, real-world test

The honest way to test that is to point the tool at real websites that we don't control and have no reason to score in any particular way, and ideally ones where you'd expect a serious security posture, so a weak result would clearly mean something. We chose two real, well-known businesses' public websites for exactly this. Running the tool against real sites, rather than only our own, removes any suspicion that it's tuned to flatter a site it already knows.

2 · What "a working tool" would actually look like

Before seeing the results, it's worth being clear about what would count as the tool working versus failing, because otherwise any result can be rationalised after the fact. A broken tool tends to fail in one of two obvious ways: it scores everything as perfect (so it isn't really checking anything), or it fails everything (so it's just throwing errors and flagging problems that aren't there). A genuinely working tool does neither: it produces different, believable scores for different sites, reflecting the real differences in how well each one is actually protected.

3 · The results, real, and meaningfully different

That's exactly what happened. The two sites scored clearly differently from each other, and both scores were plausible for what they were. One site was missing several important protections and scored notably lower as a result. The other had a number of protections properly in place, but was still missing some others, and scored better, though not perfect. Two real sites, two different, sensible scores, each one traceable to concrete things the site did or didn't have. Neither an all-pass nor an all-fail.

4 · Why that specific pattern is the reassuring one

The differentiation is the whole point, and it's worth spelling out why. If both real sites had scored a perfect 100, that would have been a warning sign that the tool wasn't genuinely testing anything, a rubber stamp. If both had scored zero, that would have suggested it was broken and flagging phantom problems. Two different, defensible scores, each tied to real, nameable gaps, is precisely the signature of a tool that is actually inspecting each site on its own merits and reporting honestly. It's the good outcome, not just an outcome.

5 · Outcome

The test confirmed the tool produces credible, real-world-plausible results rather than a fixed or broken score, which is what gave us the confidence to go on and use it for the broader testing that follows in this write-up. A checker you haven't proven is honest is one you can't safely rely on; this is the step that earned that reliance.

Key points

• A checker that always says "fine" is worse than useless, it gives false confidence where it's most dangerous.
• We tested our tool against two real, well-known businesses' sites, ones we don't control.
• A working tool gives different, believable scores for different sites, not all-pass, not all-fail.
• The two sites scored clearly differently, each traceable to real, nameable protections they had or lacked.
• That pattern is the reassuring one: it proves the tool genuinely inspects each site rather than rubber-stamping.

Questions & answers

Why not just test it on your own site? A tool might be unconsciously set up to give your own site a good result. Testing real sites you don't control is a fairer, more honest check of whether it really works.

Why would two perfect scores be a bad sign? Because real websites genuinely differ in how well they're protected. If everything scores perfectly, the tool probably isn't really checking anything.

What made the results trustworthy? The two sites got clearly different scores, and each score matched real, specific protections the site had or was missing, not a random or fixed number.

Why do this before the other testing? Everything that follows depends on the tool being honest. This is the step that proved it, before we relied on it further.

Why build a second tool at all

Our public security audit checks one website at a time, the way a visitor's browser would. That's exactly right for a member of the public checking their own site, but it makes testing the checking logic across many sites slow and manual: you'd have to sit and run it by hand, one site after another, and copy down each result. So we built a separate companion tool that runs the same kind of safe, passive checks, the ones that only look at a page the way any browser sees it, but automatically down a whole list of websites in one pass, straight from our own server. Same checks, many sites, no manual clicking.

It's worth being clear this is a genuinely separate program from the public audit, not a change to it. The public tool on the website was never touched; this is a standalone script we wrote for our own testing, so we could put the checking logic through its paces against a wide, varied range of real sites quickly.

1 · Keeping it strictly to safe, passive checks

The tool does only passive checks, the exact same category of thing a normal web browser does when it loads a page and reads the response. It sends no attacks, tries no break-ins, and does nothing a site owner could object to; it simply looks at what every visitor's browser already sees: the security-related settings a site sends back with its pages. That restraint is deliberate and important, it's what makes running it against websites we don't own completely legitimate, exactly as looking at any public page in a browser is legitimate.

2 · Choosing a deliberately varied set of test sites

To really put the checking logic through its paces, we needed sites that are genuinely different from one another, not ten near-identical sites that would all pass or fail together and prove nothing. So we chose the official websites of 10 of the biggest website-building platforms in the world. These are run by large, sophisticated companies with real security teams, and they're built on very different underlying technology from one another, which makes them an excellent, demanding, and fair stress test: if the logic handles this much variety correctly, it's robust.

3 · What the results showed, real variation, not uniformity

The results varied genuinely and sensibly from platform to platform, which is exactly what you want to see. Some scored very well, with barely any issues. Others, even these big, capable companies, had real, specific, identifiable gaps in their security settings: things like missing protections on the small pieces of data a site stores in your browser, or missing security-related instructions in the pages they serve. A few even openly advertised, in their pages, exactly which platform they were built on, a small information leak in itself. The point isn't to single any of them out; it's that the tool found real, different, nameable things on different sites, which is precisely how you know it's genuinely inspecting each one rather than producing a canned answer.

4 · Why this was a meaningful test of the logic

This mattered because it proved the checking logic behaves correctly and consistently across a wide range of real, very different websites, not just the one site we started from. It's easy for a checker to work on the site it was built and tested against, and then behave strangely the first time it meets a site built differently. Running it across ten genuinely different, professionally-built platforms and getting sensible, varied, defensible results from each is strong evidence that the logic is sound in general, not just narrowly tuned to our own site.

5 · Outcome

The companion tool confirmed the underlying checking logic is correct and consistent across a broad, diverse set of real sites, giving real confidence in the checks themselves. And it did so using only the same safe, passive approach as the public audit, run entirely from our own machine against publicly-available pages.

Key points

• A separate companion tool runs the same safe, passive checks as the public audit, but down a whole list of sites in one pass.
• It does only what a browser does on page load, no attacks, which makes checking sites we don't own legitimate.
• We chose 10 of the biggest, most different website platforms on purpose, as a demanding, fair stress test.
• Results varied sensibly, some near-perfect, others with real, nameable gaps, proving genuine per-site inspection.
• It confirmed the checking logic works across many very different real sites, not just our own.

Questions & answers

Is this your public audit tool? No, it's a separate program we built just for testing. The public tool on the website was never changed; this one simply reuses the same safe checks to try them across many sites at once.

Is it OK to run this against sites you don't own? Yes, it only looks at a page the way any visitor's browser does. It sends nothing harmful and tries no break-ins, so it's the same as viewing a public page.

Why test 10 different platforms instead of 10 similar sites? Because difference is the whole point. Ten near-identical sites would all behave the same and prove little; ten very different ones that each give sensible results show the tool really works in general.

What did "varied results" actually look like? Some platforms scored very well; others had real, specific gaps, and a few even advertised which platform they were built on. Different, nameable findings on different sites is exactly how you know it's inspecting each one properly.

The moment of doubt, and why we welcomed it

Our own security-checking tool gave the main site a perfect 100 out of 100. That should feel good, but a perfect score is exactly the kind of result that deserves suspicion rather than celebration, because the most dangerous failure a checking tool can have is telling you everything's fine when it isn't. So instead of taking the win, we did the honest thing and cross-checked it: we ran the very same site through a completely independent, well-known security checker built by a major technology company, to see whether it agreed.

It didn't. The independent checker scored the site 80 out of 100, and it pointed to one real, specific weakness in a particular security setting, a weakness our own tool had missed entirely and papered over with full marks. That gap between "100 from us" and "80 from them, with a named problem" is the whole story of this section: a real bug in our own tool, caught precisely because we didn't trust our own perfect score.

1 · Not dismissing the disagreement

The easy, comfortable response to that disagreement would have been to wave it away, to assume the other tool was being fussy and ours was right. We deliberately didn't. When a trusted independent tool disagrees with yours and names a concrete problem, the honest assumption is that yours might be wrong, and the only way to know is to look. So rather than defend our score, we went and read our own tool's actual underlying code to find out exactly why it had given full marks where a respected checker saw a real fault.

2 · What the code was actually doing

Reading the code revealed the bug plainly, and it was a genuinely instructive one. Our check for this particular security setting was only checking whether the setting was present at all, not what it actually said. It's the difference between checking that a door has a lock fitted and checking whether that lock is any good or left wide open. Because of that, a site could have the weakest, loosest, most permissive possible version of this setting, one that effectively cancels out the protection the setting is supposed to provide, and still sail through our check with full marks, purely because something was there. Present-but-useless was being scored identically to present-and-strong.

3 · Fixing it against the real standard

We rewrote the check properly. Instead of merely asking "does this setting exist?", it now inspects what the setting actually contains and judges whether it's genuinely strong, using the real, well-established rule for what makes this setting strong (that it must not include the self-defeating options that cancel its protection). To be clear about what we did and didn't do: we did not change our tool to produce the same score as the independent one. The two use completely different scoring scales, and we're not claiming an 80 or trying to reproduce it. The independent tool didn't set our score, it simply helped us spot that our own check was wrong. All we changed was the check itself, so it now judges this setting correctly instead of rubber-stamping it.

4 · Testing the fix three ways before trusting it

A fix to a checking tool has to be tested as carefully as anything else, because a check that's wrong in a new direction is no better than the old one. So before putting it live we tested it three ways: we confirmed it correctly failed the site's real, currently-weak setup (the thing the independent tool caught); confirmed it correctly passed a properly strict, secure setup (so it isn't just failing everything now); and confirmed it correctly failed when the setting was missing entirely. Fails the weak case, passes the strong case, fails the absent case, all three, so we know it's discriminating correctly rather than just flipped to always-fail.

5 · Outcome

Once deployed and re-tested on the real live site, the tool now correctly and honestly reports this as a genuine issue needing attention, with a clear, accurate explanation of exactly what's wrong, instead of hiding a real problem behind a false, reassuring 100/100. The tool is now more honest than it was, which for a security checker is the most important quality it can have. And it was our own willingness to distrust a flattering result that surfaced the bug in the first place.

Key points

• Our tool scored the site a perfect 100; an independent, trusted checker scored it 80 and named a real weakness ours missed.
• We cross-checked rather than celebrated, a perfect score is the one that most deserves suspicion.
• The bug: our check only asked whether a setting existed, never whether it was any good.
• We rewrote it to judge the setting's real content, not to change our score to match the other tool (different scales); it just helped us find the bug.
• We tested the fix three ways (weak fails, strong passes, missing fails) before putting it live.

Questions & answers

Why not trust your own 100/100? Because a perfect score is exactly what a broken checker would also produce. The safest response to your own tool saying "all perfect" is to have an independent tool check the same thing.

What was actually wrong? Our check only looked at whether a security setting was there at all, not whether it was strong. So a site with the weakest possible version of that setting still got full marks.

How did you fix it? We rewrote the check to look at what the setting actually says and decide whether it's genuinely strong. We didn't change our tool to output the other tool's number, the scales differ, we just stopped it scoring a self-defeating setting as safe.

How do you know the fix is right? We tested it three ways: it now correctly fails the weak real setup, correctly passes a properly strict one, and correctly fails when the setting is missing, then verified it on the live site.

A gap, not a bug, something we simply weren't checking

The previous section was about a check that was wrong. This one is about a check that was missing entirely, a genuine blind spot rather than a mistake. When we cross-checked our tool against the independent one, it tested one thing ours didn't look at all: whether the scripts and stylesheets a website loads from other websites carry a special safety verification. Being honest about a missing check is just as important as fixing a broken one; an incomplete checker gives false confidence in a quieter way.

Here's the real-world risk this addresses, in plain terms. Most websites pull in some code from outside sources, a font here, a script from another company there. Normally your browser just trusts and runs whatever those outside sources send. The safety verification in question lets a website say, in advance, "this outside file should look exactly like this, and if it doesn't, don't run it." That protects visitors if one of those outside sources is ever hacked or tampered with: instead of every visitor's browser silently running the altered, malicious code, the browser notices it doesn't match and refuses. It's a genuinely valuable protection, and our tool wasn't checking for it.

1 · Building the missing check

So we built and added it ourselves. The check reads through a page, finds every script and stylesheet that's loaded from outside the site's own address, and works out whether each one carries that safety verification or not, flagging the ones that don't. We built it on top of the same reliable page-reading component the tool already used elsewhere, rather than bolting on something new and untested, so it fits cleanly with how the rest of the tool works.

2 · The second, separate problem, it worked but didn't show

Once the check was working correctly behind the scenes, a second and quite different problem appeared: the results page that visitors and admins actually see didn't display the new check anywhere, even though it was running and scoring correctly out of sight. This is a good example of how two parts of a system have to agree with each other. The part that does the checking now knew about the new check, but the part that displays the results keeps its own separate list of checks it knows how to show, and that list hadn't been told the new check existed. So the check ran, scored, and then vanished before anyone could see it.

3 · Fixing the display side too

The fix was to add the new check to that display list as well, matching exactly the format every other check already used, so it slots in looking and behaving like a native part of the page rather than an afterthought. It's a small change, but it's the difference between a check that quietly works where nobody can see it and one that actually informs the person reading the report. A check that runs but never surfaces is, from the reader's point of view, not really there.

4 · The honest final score

With both parts fixed and live, the check itself, and its display, the new check now appears correctly on the results page with a clear explanation, and the main site now scores 93 out of 100, correctly passing 22 of 23 checks in total. The one remaining issue is the real CSP weakness described in the previous section, now accurately reported rather than hidden. That's the honest picture: a genuine, nearly-complete score with the one real outstanding item shown plainly, which is far more useful than a flattering but false perfect mark.

5 · Outcome

A real protective check that was entirely absent is now present, working, and visible, closing the last gap between our tool and the trusted independent one, and giving anyone who runs the audit a fuller, more honest picture of a site's security than before.

Key points

• This was a missing check, not a broken one, a genuine blind spot the independent tool exposed.
• It checks whether outside scripts/styles carry a safety verification so a tampered file won't run in a visitor's browser.
• We built the check on the tool's existing, proven page-reading component.
• A second problem: it worked but didn't show, the display side kept its own list and didn't know the new check existed.
• Fixing both parts, the site now scores 93/100 (22/23), with only the real CSP issue correctly still flagged.

Questions & answers

What does this new check protect against? If a website loads code from an outside source and that source is ever hacked, this protection lets the browser notice the code has changed and refuse to run it, protecting every visitor instead of silently running the tampered version.

Why did the check work but not show up? The part that runs checks and the part that displays them keep separate lists. The checking part knew about the new one; the display part didn't, so it ran but never appeared until we updated the display side too.

Why does the score drop from 100 to 93? Because 93 is the honest number. The old 100 hid a real problem; 93 reflects a near-complete, genuine result with the one real outstanding issue shown clearly.

Is one remaining issue a bad sign? No, it's an honest one, and it's the CSP weakness from the previous section, now correctly reported. A tool that shows real remaining issues is doing its job.

Detecting a problem is not the same as fixing it

The earlier sections found and correctly reported the security-setting weakness. This section is about actually fixing it properly, and being completely honest that the fix is built but not yet fully applied. There's an important, tempting shortcut here that we deliberately did not take: you can make that weakness "go away" instantly by simply loosening the setting and moving on. But that's not a fix, it's hiding the problem, and worse, blindly tightening or loosening this kind of setting risks breaking real, legitimate features on the site, like analytics or visitor-tracking scripts that may depend on the current arrangement. A change that silently breaks working features is not an improvement. So we chose the slower, correct path: understand exactly what's there first, then fix it in a way that can't break anything.

1 · Investigating before changing anything

We started by looking closely at the homepage to understand what the setting is actually protecting. We found it has only a small handful of blocks of code written directly into the page itself (rather than loaded from separate files). Crucially, we checked whether any of them use a particularly risky kind of on-the-fly code execution, the kind that would genuinely require the very loosest, most permissive version of this security setting. None of them did. That's a significant finding, because it means the most dangerous part of the current permissive setting isn't actually needed at all on that page and can very likely be removed outright, tightening security with no loss of function.

2 · Building a tool to do it properly, at scale

A website isn't one page, though, so a real fix has to work across the whole site. So we built a tool that does this properly and at scale. It scans every single page on the site, finds every one of those directly-written code blocks, automatically removes exact duplicates, since many pages reuse the same few blocks, like a shared navigation-menu script that appears on every page, and then calculates a unique digital "fingerprint" for each genuinely different one. The point of that fingerprint list is what makes the fix safe: instead of telling the site's security settings "allow any directly-written code to run" (the loose, risky current state), you can tell them "only ever allow exactly these specific, known, pre-approved blocks, and nothing else, from anywhere." That's a dramatically safer posture, and because it's built from the real code already on the site, it does it without breaking any of the legitimate code that's supposed to be there.

3 · Why fingerprinting is the safe way to tighten this

It's worth being clear why this approach is the careful one. Loosening the setting weakens everyone's protection. Tightening it carelessly breaks the site. Fingerprinting threads the needle: it tightens the setting all the way down to "only the exact code we already know and trust", which is as strict as it can possibly be, while guaranteeing that every piece of legitimate code currently on the site is on the approved list and keeps working. You get maximum strictness and zero breakage at the same time, but only if the fingerprint list genuinely covers every page, which is exactly why the remaining step matters.

4 · Where this honestly stands

Here's the honest status. We successfully tested the tool on the homepage alone, and it correctly found and fingerprinted the handful of code blocks there. But the website as a whole has just over 1,000 separate pages. The tool is fully built and handed over, but running it across the entire site, and then actually updating the live security settings with the complete, site-wide fingerprint list, has not been done yet. Until that happens, the fingerprint list would be incomplete, and applying a partial list would risk blocking legitimate code on the pages not yet scanned. So the safe thing is to complete the full scan first.

5 · Outcome (open)

The proper fix is designed, built, and proven on a single page, but not yet rolled out site-wide, so the underlying weakness is still present on the live site as things stand. This is included precisely because an honest write-up records the things that are built-but-not-finished, not only the completed wins. The tool to do it right exists; the site-wide run and the live settings update are the remaining work.

Key points

• Detecting the weakness isn't fixing it, this is the proper fix, built but honestly not yet fully applied.
• We refused the shortcut of just loosening the setting (hides the problem) or tightening blindly (breaks real features).
• Homepage check found only a few directly-written code blocks and none needing the most dangerous permission.
• We built a tool that scans every page, dedupes shared blocks, and "fingerprints" each unique one for an exact allow-list.
• Open: the site has ~1,000 pages; the full scan and the live settings update aren't done, so the weakness is still live.

Questions & answers

Why not just switch the weak setting off now? Because blindly tightening it would break legitimate code on pages not yet accounted for. The safe fix needs the full list of trusted code from every page first.

What is the "fingerprint" actually for? It lets the site say "only allow exactly these known, trusted blocks of code to run." That's far safer than "allow anything", and it's built from the real code already on the site, so nothing legitimate breaks.

Why does having ~1,000 pages matter? The trusted-code list has to cover every page. Applying it after scanning only the homepage would block legitimate code on the other pages, so the whole site must be scanned first.

So is the site fixed? Not yet, honestly. The tool that does it right is built and proven on one page, but the full run and the live update remain, so the weakness is still present for now.

Not a security issue, a mystery worth ruling out properly

This last item isn't a security fix at all; it's an honest investigation into something that looked odd and turned out to be harmless, included because ruling things out carefully is part of the same disciplined mindset as fixing real problems. A search-performance report showed a specific phrase describing the business favourably suddenly appearing in Google's results far more often than the week before, a genuinely large jump. The phrase didn't sound familiar, and an unfamiliar claim about your own business showing up in search is exactly the sort of thing you should chase down rather than either celebrate or ignore. Where was it coming from? Had something been added to the site without our knowledge? We investigated properly rather than assuming.

1 · Searching every file on the whole server

We started with the most thorough possible check: we searched every single file on the entire server, every domain, every file type, no exceptions, for that exact phrase. The only place it appeared was inside files belonging to completely unrelated third-party software that the site uses behind the scenes (marketing text in another product's bundled documentation), with nothing to do with this business's own content at all. So it wasn't in anything we'd written or published.

2 · Checking the files meant for AI and search engines

Next we checked the files specifically meant to be read directly by AI tools and search engines, the ones that describe a site to automated systems. If the phrase had been planted somewhere to influence how machines describe the business, this is where it would be. It wasn't there either. Nothing in any of those files contained it.

3 · Widening the net, and following the trail to its real source

We then broadened the search to catch near-variations, different spacing, hyphens, word order, in case it was present in a slightly different form. That turned up some old, leftover working files sitting in a private folder that isn't reachable from the internet at all. Digging into those, we traced the actual source: the phrase had been accidentally captured as sample test data by a separate tool used for checking lots of different websites at once, and it originally belonged to a completely different, unrelated real company. It had nothing to do with this business, it was just incidental data left over in a working folder. We also confirmed that folder returns a "not found" response from the internet, so nothing in it can be reached or read by any search engine or visitor.

4 · Checking everywhere else the business appears

To be genuinely thorough, we also checked everywhere off the site that the business appears. Every business directory listing was inspected, all of them plain factual entries (address, phone, category), with no promotional wording. Every social-media profile was checked too; several of those platforms deliberately block automated checking tools, so those were checked personally, by hand, rather than skipped. Nowhere did the phrase appear.

5 · The actual, boring, reassuring explanation

So the phrase genuinely does not exist anywhere connected to this business, not on the website, not in any file meant for AI tools, not in any directory listing, not on any social profile. The explanation turns out to be completely normal, well-documented behaviour: search engines can show a page as relevant to a search without that search's exact wording appearing anywhere on the page. They increasingly match on what a page is broadly about, its general topic and meaning, rather than on literal word-for-word matching. In other words, Google decided the site was relevant to that favourable phrase based on the site's overall subject matter, not because anyone wrote those words anywhere. We confirmed this is standard behaviour via the search engine's own official help community and several independent industry sources.

6 · Conclusion, nothing to fix, and that's the finding

There was nothing to fix, because there was genuinely nothing wrong or hidden anywhere to begin with. That is itself a worthwhile result: a surprising signal was chased all the way to the ground and shown to be benign, with certainty rather than a shrug. Sometimes the honest, valuable outcome of an investigation is a confident "there is no problem here", and being able to say that, having actually checked everything rather than assumed, is worth just as much as a fix.

Key points

• A favourable phrase spiked in Google's results; it didn't sound familiar, so we investigated rather than assumed.
• A whole-server search (exact and near-variants) found it only in unrelated third-party files and private, unreachable test data, never in the site's own content.
• Files meant for AI/search engines, every directory listing, and every social profile were all checked, some by hand.
• The cause is normal, documented behaviour: search engines rank a page for a phrase's topic, not its exact words.
• Nothing to fix, a confident "no problem here", reached by actually checking everything.

Questions & answers

How can Google show a page for a phrase that isn't on it? Search engines increasingly match on what a page is broadly about, not just its exact words. So a page can be shown for a phrase it doesn't literally contain, based on its overall topic.

Was something added to the site without your knowledge? No. We searched every file on the whole server and the phrase only appeared in unrelated third-party software and in private files that aren't reachable from the internet, nothing in the business's own content.

Why check social profiles and directories by hand? Some of those platforms block automated checking tools, so an automated-only search would miss them. Checking personally makes sure nothing was overlooked.

If nothing was wrong, why does this count as a result? Because a surprising signal was chased all the way down and shown to be harmless with certainty. A confident "there's genuinely nothing wrong here" is a real and valuable outcome.

Making the audit more complete, then proving it holds up

The earlier testing showed the security audit was sound, but sound isn't the same as complete. A checklist that only covers some of what matters can still miss real things, so we went through the audit properly and added every meaningful check it was lacking, taking it from forty-four checks to fifty-four. Then, crucially, we didn't just trust that the new, bigger version worked, we put it through the hardest test we could: running it against two hundred different real websites and inspecting not only the results it calculated, but what it actually displayed on the page, to be certain the two always agreed.

1 · Adding the missing checks, honestly

We added a full set of checks the audit didn't previously make: modern browser-isolation settings, a safe test for an old and risky web method, certificate breadth, mail-branding records, and several others. The guiding rule throughout was honesty, not box-ticking. Many of the new items are genuinely optional, a site is not insecure for lacking them, so those are shown as neutral information, never as a red failure. A deprecated setting that modern browsers ignore is labelled as exactly that, with a note that any scanner still demanding it is out of date. The point of a bigger audit is to see more, not to invent more things to fail people on.

2 · Testing the results and the display together

A subtle but important point: a security tool can calculate the right answer and still show the wrong thing. The number it works out internally and the list of results a person actually reads on screen have to match exactly, or the report misleads even when the underlying logic is correct. So we tested both layers at once, the calculated result and the rendered page, and checked on every single site that the totals reconciled, that every result shown was accounted for, and that nothing extra was quietly displayed that the summary didn't count.

3 · The first hundred sites, and a real bug caught

We ran the audit against one hundred major websites and it behaved correctly on ninety-nine of them. The hundredth, a large government site, revealed a genuine display fault: because that site had a number of known software vulnerabilities, the page listed each one as if it were a separate check, inflating the visible list beyond the number the summary counted. The calculation was right, the vulnerabilities were real and correctly scored once, but the way they were shown didn't line up with the count. This is exactly the kind of fault that only appears on a site with that specific characteristic, which is precisely why testing across many varied real sites matters.

4 · Fixing it the honest way

The fix kept every vulnerability fully visible, hiding them would have been dishonest and defeated the point, but showed them as supporting detail beneath the single check that counts them, rather than as separate checks in their own right. The finding is reported once and counted once; the detail of exactly which vulnerabilities were found is shown in full underneath. Visible and honest, but no longer distorting the count.

5 · A second hundred, completely different sites

To be sure the fix worked and that the tool wasn't merely tuned to the first hundred, we ran it again against a different hundred sites, deliberately chosen to be varied: international sites, publishing sites built on common software (the exact kind likely to have the vulnerability pattern that caught us the first time), online shops, developer services, forums and government sites. This time all one hundred passed cleanly, results and display in perfect agreement on every one, including the sites that did have known vulnerabilities, which now displayed correctly. Two hundred different real sites in total, both the calculation and the on-screen report checked on each, every one reconciling.

6 · Outcome

The audit is now both broader and proven: fifty-four honest checks, validated on two hundred real websites at both the calculation and display level, with the one fault that testing uncovered found and fixed. A bigger checklist is only an improvement if it's still accurate; this is the work that confirmed it is.

Key points

• The audit was expanded from 44 to 54 checks, adding every meaningful check it lacked.
• New optional items are shown as neutral information, never as failures, a bigger audit should see more, not fail people on more.
• We tested the calculated result and the displayed page together on every site, so the two can never disagree.
• Testing on 100 sites caught a real display fault (a site's known vulnerabilities inflating the visible list); it was fixed so they show as detail, fully visible but counted once.
• A second, different 100 sites then passed cleanly, 200 real sites in total, every one reconciling at both layers.

Questions & answers

Does adding more checks just mean failing sites on more things? No, that would be the wrong kind of tool. Many of the added checks are genuinely optional and are shown as neutral information, not failures. The aim is to see more accurately, not to manufacture problems.

Why test what's displayed as well as what's calculated? Because a tool can work out the right answer and still show a misleading list on screen. If the number it counts and the results a person reads don't match, the report misleads even when the logic is sound, so both have to be checked.

Was hiding the vulnerabilities the fix? No. Hiding real findings would be dishonest and defeat the point of an audit. Every vulnerability stays fully visible; the fix simply shows them as detail under the single check that counts them, so the finding is reported once and counted once.

Why run a second, different hundred sites? To prove the tool isn't merely tuned to the first set and that the fix genuinely worked, especially on the kinds of site that had triggered the fault. Passing a fresh, varied hundred is far stronger evidence than re-running the same list.