Is my website secure? A free check

“Is my website secure?” is really two questions, and only one of them can be answered from outside.

The first is about what any visitor, browser or mail server can already see: the certificate, the headers your server sends back, the DNS records for your email. That takes about thirty seconds and needs no login. The second is about everything behind the front door, and that takes a person with access.

I built a free website security check for the first question. This is what it looks at, how to read the colour it gives you, and where it stops.

What it checks

Twelve to fourteen things, depending on what your site does. They fall into three groups.

The connection. Does the site answer over HTTPS at all? Is the certificate valid, issued for this name, and not about to expire? Is it using TLS 1.2 or 1.3 rather than something older? And when somebody types the address without https, do they get sent to the secure version or served the unprotected one?

The headers. HSTS, which tells browsers never to try plain HTTP again. A Content Security Policy. X-Content-Type-Options, clickjacking protection, Referrer-Policy. Whether the server announces its exact software version, which hands an attacker a shopping list. And, if the home page sets cookies, whether they carry the Secure and HttpOnly flags.

The email records. SPF, DKIM and DMARC. Nobody thinks of these as website security, and they are the ones I would fix first, because they are what stops someone sending convincing invoices in your name. I wrote about my own DMARC check passing domains that had no protection, so I am a bit fussy about reading the record rather than just finding it.

What red, amber and green mean

Red means something a visitor will notice, or a score under 50. The site does not answer over HTTPS, or the certificate is expired, issued for a different name, or not trusted. Browsers put a full-page warning in front of people when that happens, so it is not subtle.

Green needs a score of 80 or more and no outright failures.

Amber is everything in between, and it is the common result. A site with a good certificate, no HSTS and no Content Security Policy lands there, and nothing about that says you have been hacked. These are gaps. They make an attack easier or a phishing email more believable, and most of them are one line in a server config.

The scoring is mine. Pass counts full marks, “worth fixing” counts half, a fail counts nothing, and the certificate and HTTPS checks weigh the most. It is a judgement call written down, not a standard, and I would rather say so than dress it up.

What I would fix first

The certificate, if it has expired or is close. Then the email records. Then the headers, cheapest first.

The headers deserve a warning. Setting them is easy, and getting them to actually arrive is not. nginx throws away every inherited add_header the moment a child block sets one of its own, so a site can have the headers in its config and still send none of them on its HTML pages. I found that on my own sites, and wrote it up. It is why the check reads what the server really sends rather than what the config says.

What a green does not tell you

This is the important bit.

The check looks at one page over HTTPS, one over plain HTTP, the certificate handshake and some DNS lookups. It cannot see open ports, the software running behind the site, who has an account on it, or what is in the code. A green means the front door is shut. It says nothing about the rooms.

That gap is what a proper audit is for. Mine is read-only: it changes nothing without your say-so and every finding comes with the evidence it was read from. If the check comes back amber or red and you want a person to look at the rest, the first call is free and takes about half an hour.

What I left out on purpose

I did not add a port scan.

It would have been the most impressive-looking thing on the page, and it is exactly what I would not want a stranger running against my own servers. A public form that probes other people’s ports without their say-so is not a health check. So the tool asks you to confirm the site is yours or that you have permission, and it never touches a port other than 443 and 80.

The other thing a tool like this has to get right is less obvious. It fetches whatever address a stranger types in, and that is a classic way to turn a server into a weapon: type in an internal address and make it fetch something it should never reach. So it resolves the name itself and refuses anything that points at a private or internal range. It then connects to the exact address it checked rather than looking the name up again, because a hostile DNS server can answer “public” the first time and “internal” the second. I tested it against names built to resolve to private space, and against sites with expired, self-signed and wrong-name certificates, which it catches.

My own domain

I ran it on this site. Green, 96 out of 100, with one finding: my DMARC policy is still set to monitor only. That is the honest state of the domain you are reading this on today.

Try it

Run it on a domain you own: laurentiu-niculescu.co.uk/tools/site-check. If it comes back amber or red, start with the items marked “Fix this”.

There are two other tools on the tools page. One asks six questions about an app you want built and tells you how much of it AI could plausibly draft, which is the practical companion to can I build my business app with AI. The other builds a project roadmap with a rough timescale.