The Website That Went Dark for Four Days

Nobody hacked it. The domain simply expired.

A few years ago, a government website I was helping keep an eye on went offline. It stayed dead for four days.

There was no sophisticated breach. No ransomware note, no defaced homepage, nothing you’d ever read about in a threat report. The domain registration had just lapsed. The renewal notices were quietly funneling into the inbox of a guy who had left the job months prior. Those emails bounced into the void, the clock ran out, and constituents looking for public information got a DNS error instead.

The outage itself wasn’t what stuck with me — it was how completely ordinary the cause was, and how long it took anyone to notice. There was no adversary to blame. Just an administrative failure where a timer ran down while nobody was looking.

The longer I build and maintain web infrastructure, the more I realize this isn’t an anomaly. It’s the norm.

The Boring Stuff is What Actually Breaks

If you only read security blogs, you’d think the biggest threat to your site is a state-sponsored zero-day. Sometimes it is. Far more often, it’s this:

• A TLS certificate quietly expires on a Saturday, and every visitor gets a massive browser warning until you wake up on Monday.
• A .env file ends up in the web root during a rushed late-night deploy and sits there, publicly readable, for six months.
• A WordPress plugin stops being maintained, and nobody notices because the frontend still renders fine.
• The mail server’s IP lands on a blacklist, and your transactional emails silently drop into the abyss.

None of these require an attacker. They’re all just entropy — things drifting out of a correct configuration while nobody is looking. And they share one property that makes them particularly nasty: the site keeps working perfectly right up until it doesn’t. There’s no dashboard glowing red to warn you, because nothing looks broken from the outside.

Most enterprise security tooling assumes you have a dedicated SOC team staring at monitors all day. But most sites in the wild don’t have that. They have one solo developer, or a small agency juggling forty clients, or someone trying to wear three different hats at once.

So I built a tool for that exact situation.

What Aion Security Actually Does

Aion Security scans a domain, tells you exactly what’s wrong with it in plain English, and then keeps watching so it can alert you the second something degrades.

You don’t need an account to run a free scan. You just drop in a URL, and within a few seconds, you get a graded breakdown covering the things that actually cause headaches:

• TLS/SSL: Certificate validity, expiration countdowns, weak ciphers, and whether you’re still accepting outdated protocols.
• Security headers: HSTS, CSP, X-Frame-Options, and a no-nonsense explanation of what each one actually prevents.
• Email spoofing: SPF, DKIM, and DMARC configurations, checking if anyone can impersonate your domain.
• Exposed files: Hunting for .env, .git, backups, and other sensitive artifacts that have no business being publicly readable.
• Cookie security: Checking for Secure, HttpOnly, and SameSite flags.
• IP reputation: Cross-referencing blacklists to see if your server is silently eating your emails.
• Domain expiry: Exactly the failure mode from my story above.
• DNS hardening: CAA records and DNSSEC.
• WordPress: Version detection, stale plugins, and exposed admin endpoints.

The paid plans add the piece that actually solves the entropy problem: continuous monitoring. The scan runs on a schedule, and you get an email only when something gets worse. It’s not a daily digest you’ll eventually train your brain to ignore. It’s a targeted alert when your grade drops, your cert is about to die, your IP gets blacklisted, or your site goes down. It also includes uptime monitoring and a dependency scanner that checks your package-lock.json, requirements.txt, or composer.lock against known vulnerability databases.

Why I Care About Not Crying Wolf

Here’s the reality of building a tool like this: a monitoring tool is only as valuable as your willingness to believe its alerts.

The moment a system sends you three warnings that turn out to be false positives, you start skimming. After the fifth, you set up a Gmail filter. By the time an alert that actually matters comes through, it’s buried in a folder you haven’t opened in weeks. A noisy security tool isn’t just annoying; it’s actively worse than having no tool at all, because it trains you to ignore the exact signal it was built to send.

So I spent a long time actively trying to prove my own scanner wrong, and succeeded way too many times.

I audited every single check, hunting specifically for false positives rather than just validating that it caught real issues. I found nine. All nine are now fixed, with regression tests pinning them in place. A few examples, because the specifics matter:

• The credential-file detector was flagging plain text. It was looking for username:hash patterns in /.htpasswd. The problem? The regex essentially matched any line shaped like word:word. A plain-text 404 page would trigger it. A YAML config would trigger it. Even a bare URL on its own line (https://example.com) would match. The tool would tell a developer their password file was exposed just because their error page contained a link.
• The certificate check only tested one server out of many. If a domain resolved to multiple IPs — like anything behind a CDN or load balancer — it just checked whichever one DNS returned first. If one node had a valid cert and another didn’t, the site would bounce between "fine" and "critical" depending on DNS round-robin routing, blasting out useless state-change emails.
• The WordPress check penalized people for doing the right thing. It flagged an exposed admin login if the page simply contained the words "log in." But a site that had correctly hidden wp-login.php often redirects to the homepage instead — and if that homepage had a "Log in" button in the nav bar, it got flagged.
• The CSP check panicked over scoped asterisks. It looked for an * in the Content-Security-Policy and called it dangerous. But https://*.your-cdn.com is a perfectly safe, scoped source. Sites with tight, careful policies were getting slapped with a "B" grade just for using a wildcard on a CDN subdomain.

Every single one of these flaws shares a common thread: as a user, you’d have no way of knowing the tool was wrong. If a scanner tells you your .env is exposed, you don’t assume the tool is buggy. You panic, you drop what you’re doing, and you waste an afternoon chasing ghosts.

I would rather miss a theoretical edge-case than invent a fake problem. That’s a deliberate tradeoff. Several checks are now much stricter, and findings that are only technically defensible are reported as informational notes rather than dragging down your grade.

What It Doesn’t Do (And Won’t)

It’s equally important to define what a tool isn’t:

• It is not a penetration test. It looks at what a domain exposes to the public internet. It doesn’t try to break in, and it never will. There is zero active exploitation.
• It is not a WAF. It tells you about problems; it doesn’t block malicious traffic.
• It doesn’t match server version strings against CVEs. I looked hard at building this and scrapped it. Linux distributions constantly backport security fixes without bumping the main version number, meaning version-string matching produces highly confident, completely wrong answers at scale.
• It can’t see inside your code. Business logic flaws, authentication bypasses, or SQL injections in your backend are invisible from the outside.

It covers the layer that is genuinely verifiable from the outside, and it does it carefully.

Practice What You Preach

If you’re going to build a security tool, you have to hold it to its own standards.

aionsecurity.io publishes a security.txt file with a real, monitored contact address. It enforces HSTS, has SPF, DKIM, and DMARC configured with reporting enabled, runs a Content-Security-Policy, and publishes an MTA-STS policy so mail sent to it can’t be quietly downgraded to plaintext.

Two of those are deliberately not fully switched on yet. The CSP is in report-only mode and the MTA-STS policy is in testing mode, which means both are collecting violation reports without enforcing anything. That’s on purpose: a CSP that blocks a script you forgot about breaks your site, and an MTA-STS policy with one wrong hostname stops your mail arriving. You watch the reports first, then you enforce. I’d give you the same advice, so I’m taking it myself.

If you scan the site with its own tool, you’ll see exactly where it stands — including the minor things that still aren’t perfect.

Finally, there’s a permanent scan opt-out. If the scanner has hit a domain you own and you’d prefer to be left alone, just email the address in our security.txt and it’s excluded from all future scans. It seems like the bare minimum obligation for building a tool that makes outbound requests to strangers’ servers.

Try It

The scan is free, needs no signup, and takes a few seconds: aionsecurity.io

If you’re responsible for more than one site, the monitoring is $9/month for five domains and $29/month for unlimited. Or don’t pay anything and just scan your sites by hand whenever you want. I’m not trying to get rich off of this — I built it to manage my own websites and figured other people might have the same problem.

If you scan your site and something looks wrong — especially if you think a finding is a false positive — I genuinely want to hear about it, through the contact form or at the address in our security.txt. That’s how the last nine got found.