Website security monitoring
Most of what matters about a small business website can be read from outside it, without installing anything. This page covers what that check actually sees, how to decide which of the findings to act on — the answer is not the CVSS score — and the four things monitoring will never tell you.
You will be asked to create a free account before the report is shown, and the free tools refuse to scan banks, government sites and the major platforms. No card.
What a scan can see
None of this requires access. That is the point, and it is also the uncomfortable part: an attacker gets exactly the same view, for free, without asking.
Does a visitor get a warning before they get your page?
What is read
HTTPS connection, HTTP to HTTPS redirect, HSTS max-age, HSTS on subdomains, mixed content, response time, HTTP status.
Why it matters
A certificate that expired at 3am is the most public failure a small site has. Mixed content is the quieter one: a page served over HTTPS pulling one script over HTTP is a page an attacker on the same network can rewrite.
Which free browser protections are switched on?
What is read
HSTS, Content-Security-Policy, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy, Cross-Origin-Opener-Policy, Cross-Origin-Resource-Policy, X-XSS-Protection.
Why it matters
These cost nothing and are set in one place. They do not fix a vulnerable application, but several of them turn a bug into a non-event: X-Frame-Options stops your login page being framed inside somebody else's, and a Content-Security-Policy limits what an injected script can reach.
Is anything reachable that was never meant to be?
What is read
.env files, .git folders, database backups, CI configuration, debug pages.
Why it matters
This is the category that turns into an incident fastest, because there is nothing to exploit — the file is just there. A .env holds live credentials. An exposed .git folder can be reassembled into your whole source tree, including whatever was committed before somebody thought better of it.
What does the site tell the world it is running?
What is read
Framework and CMS fingerprints, server version headers, generator meta tags, published asset paths.
Why it matters
Nobody scans the internet by hand. Attackers match disclosed versions against published vulnerabilities, at scale, within days of a release. Whatever your site announces is the search term someone else is using.
Is the session cookie protected?
What is read
Secure, HttpOnly and SameSite flags on the cookies the site sets.
Why it matters
A session cookie without HttpOnly can be read by any script that gets onto the page. Without Secure it can be sent over plain HTTP. These are one-line changes in almost every framework and they are missing more often than not.
Is anything about the name itself broken?
What is read
Nameservers, nameserver redundancy, IP blacklist (DNSBL) listings.
Why it matters
One nameserver is a single point of failure for both the website and the mail. A DNSBL listing is the reason your mail suddenly lands in spam, and you will not find it by looking at your own inbox.
What else is on this domain?
What is read
Subdomains found in public Certificate Transparency logs.
Why it matters
The forgotten staging site is the classic way in. Because publicly trusted certificates must be logged, a subdomain that got a certificate is a matter of public record — which means an attacker already has this list.
How to prioritize
Every vulnerability tool will hand you a list sorted by severity. Severity is the wrong sort order when you have one afternoon, because it answers a question you did not ask.
A CVSS base score is a severity model: how much damage, how easily reached, how much privilege needed. It does not know whether anyone has ever exploited the bug. Sort a vulnerability list by CVSS and the top of it is full of critical-rated issues in software nobody attacks, while a medium-rated one that every botnet is currently using sits halfway down.
CISA, the US Cybersecurity and Infrastructure Security Agency, publishes the Known Exploited Vulnerabilities catalog. A vulnerability gets added only when there is reliable evidence of active exploitation in the wild, it has a CVE identifier, and there is a clear remediation action. It is free, published as JSON and CSV, and updated as evidence arrives.
The catalog came out of CISA's Binding Operational Directive 22-01, which requires US federal civilian agencies to remediate the vulnerabilities on it by a set due date. That is why it is short and why every entry carries a required action: it was built as a work queue, not a research database.
You cannot patch everything, and any tool that hands you every CVE for every component is handing you the problem back. KEV gives you a defensible order: anything of yours that appears on it, first, today. Then the ones with a high exploit likelihood (FIRST's Exploit Prediction Scoring System is the public model for that), and then everything else on the normal patch cycle.
Sources named here are public and worth reading directly: CISA's Known Exploited Vulnerabilities catalog and Binding Operational Directive 22-01, and the Exploit Prediction Scoring System published by FIRST.
Where it stops
Monitoring watches and reports. It does not block a request, rate-limit an attacker or filter a payload. If you need that, you need a WAF in front of the site, and it is a separate purchase.
An outside-in scan cannot tell you whether your backups run, and definitely cannot tell you whether they restore. Test a restore. That is the one control that turns a ransomware incident into a bad week instead of a closed business.
Business logic flaws, an admin account with a weak password, a staff member who can export the customer list — none of that is visible from outside. What is visible is the shape of the front door.
Verizon's annual Data Breach Investigations Report has, edition after edition, put stolen credentials and phishing among the most common ways an intrusion starts. No scanner sees that. Multi-factor authentication on email, the registrar and the hosting account does more than any scan on this page.
How DomainGuard does it
Reads what a visitor and a mail server can already see: transport, the nine security headers, exposed files, cookies, DNS, blacklists, and subdomains from Certificate Transparency. Every check is named in the report, so you can see what passed as well as what failed.
Once you prove you control the domain, a fuller scan looks at exposed services and the software the site runs. That ownership proof is required, not optional, and it is why nobody can point our scanner at someone else's site.
When CISA or the NVD publishes a vulnerability affecting software already found on one of your sites, you get told. That runs on free accounts too, because a vulnerability alert that waits for you to remember to log in is not an alert.
No. Everything on this page is read from outside: the HTTP response and its headers, the certificate the server presents, public DNS records, and public Certificate Transparency logs. Nothing is installed, nothing logs in, and nothing changes your site.
The checkup reads what any visitor already gets. The deeper vulnerability scan, which probes services rather than just reading a page, requires you to prove you control the domain first — that gate exists both to protect other people's sites and because scanning something you do not own can get you blocked or worse.
The Known Exploited Vulnerabilities catalog is CISA's list of vulnerabilities with reliable evidence of active exploitation in the wild. CVSS tells you how severe a vulnerability would be if exploited; KEV tells you that it is being exploited right now. For deciding what to fix first with limited time, the second question is the useful one.
Weekly is plenty for headers, cookies and exposed files, because they only change when you deploy. Certificate and registration expiry are worth checking daily since both fail on a known date. The vulnerability side is event-driven: what matters is being told when a vulnerability is published for software already found on your site, not re-scanning on a timer.
The checkup and a free account cost nothing, hold unlimited domains, and re-scan whenever you press the button. Free accounts get alerts when CISA or the NVD publishes a vulnerability affecting software found on your sites. Automatic re-scanning starts on Starter at $6.99 a month for 25 domains, through Apple in-app purchase.
Website security checklist
Every item above as a task, with a command to verify it yourself.
What domain monitoring is
The five layers a domain is made of, and how each one fails.
DMARC monitoring
What is inside an aggregate report, and how to read one.
Vulnerability alerts
How software found on your sites gets matched to published advisories.
The free IT checkup
Every check the scan runs, listed by name before you run it.
Cybersecurity services
When you would rather someone else did this work for you.
