What the website checker looks at
Most sites that get broken into aren't hit by anything clever. Someone left a database port open to the whole internet, or uploaded the .env file with the rest of the project, or let a certificate lapse over a long weekend. Enter a domain or a URL and the checker runs about thirty separate tests against it, one after another, so you can watch the report fill in.
The checks fall into six groups.
Domain. We look up the registration of the domain over RDAP, the modern replacement for WHOIS. If you entered blog.example.co.uk, the check goes to example.co.uk, because that is the part somebody actually pays a registrar for. Less than 30 days left counts as a warning.
SSL certificate. The certificate on port 443 has to be issued for this exact host name, signed by an authority browsers trust, and still valid. One that expires within 30 days is flagged too: that is usually the first sign that auto-renewal has quietly stopped.
Website. The home page should answer 200 over HTTPS, preferably within a second. Plain http:// should send visitors straight to https:// with a redirect. Without one, anyone who types the address by hand starts out on an unencrypted connection.
Security headers. We look for Strict-Transport-Security, X-Content-Type-Options, clickjacking protection (X-Frame-Options or frame-ancestors in the CSP) and Content-Security-Policy. A missing header is a warning, not a failure. The site still works, it just has one fewer layer between an attacker and your visitors.
Ports that should be closed. Databases, caches, remote desktops and the like: MySQL, PostgreSQL, Redis, MongoDB, RDP and a few more. None of them has any business being reachable from the internet. Redis is especially bad news, since out of the box it doesn't ask for a password. SSH and ping are left alone; having them open is normal.
Exposed files. Things that end up in the web root by accident: an .env file, the .git folder, database dumps, config backups and so on. Any one of them can hand over passwords, API keys or your whole source code.
How exposed files are detected
A lot of sites answer every unknown URL with 200 OK and a friendly "page not found" page, so the status code tells you very little. A file is reported as exposed only when its content looks like the real thing: .git/HEAD has to start with ref: refs/, a .env has to contain lines like DB_PASSWORD=, a SQL dump has to look like a dump. Redirects aren't followed, because a redirect to a login page is not the file.
We never keep or show what was found. The report says "publicly accessible" and nothing more. If you see that line, assume the secrets in the file are already out. Remove the file, block the path in the web server config, and then change every password and key it held, in that order.
Who can see the report
Every check gets its own link, which works for 24 hours, so you can send it to whoever has to fix things. The link is read-only. Checks can only be started from the IP address that created the report, and only within the first ten minutes, so nobody can use somebody else's report to scan a site. Each check runs exactly once, and the target is fixed when you press the button. Ports are checked on the IP address the domain resolved to at that moment.
A one-time check is a snapshot
Everything above can change tomorrow. A deploy wipes the redirect, a new server comes up with Redis listening on every interface, a renewal job fails. Monitors check the certificate, the domain, the site and individual ports around the clock and tell you the moment something breaks, by email, SMS, a call, Telegram, Slack, Pushover or a webhook.