How to check a website's security configuration

Does `https://` work, and does `http://` redirect to it in one hop, on every hostname and on deep paths?

Does the certificate cover every hostname served, and when does it expire?

Which TLS versions are offered? 1.2 and 1.3 are current.

Is `Strict-Transport-Security` sent, and with a meaningful max-age?

`curl -I http://example.com` and `curl -I https://example.com` answer most of this.

`Content-Security-Policy` — and read its value, not just its presence. A policy with `'unsafe-inline'` for scripts permits what CSP exists to block.

`X-Content-Type-Options: nosniff`, `Referrer-Policy`, `Permissions-Policy`.

`Server` and `X-Powered-By`, which disclose software and versions. Removing them is not protection, but it removes a free hint.

Check application routes and API responses, not only the home page — headers set by the web server often stop at the static routes.

Source maps in production, which can expose original source code.

`.env` files, backups, and configuration left in a public directory.

Directory listing enabled on a path that should not be browsable.

`security.txt`, which is not an exposure but its absence means a researcher who finds something has no documented way to tell you.

`Secure`, so they are never sent over plain HTTP.

`HttpOnly` on session cookies, so scripts cannot read them.

`SameSite`, which limits cross-site sending — and `SameSite=None` requires `Secure` or the cookie is rejected.

Cookies set before consent, which is a privacy question rather than a security one but is observed in the same pass.

Whether the application has injection vulnerabilities, authentication flaws or business-logic errors. Those require testing the application, with authorisation.

Whether the server is patched, beyond what version banners disclose.

Anything behind the TLS termination point.

A site with a perfect external posture can be vulnerable. Configuration review and security testing answer different questions, and conflating them is how a clean report becomes false assurance.

It applies the checks above across the pages it crawls rather than the home page alone: the header checks, the transport and certificate checks, the exposure checks — source maps, secrets in public files, internal paths, directory listing — and sixteen cookie checks.

Every finding carries the evidence it rests on: the header value, the URL, the cookie attribute.

It never attempts an exploit. It reads what the server presents to an ordinary client, which is why it needs no authorisation beyond owning the site.

A security review that stops at the web server leaves out the two things most often used to attack an organisation through its domain, and neither requires touching the site.

Email authentication. A domain with no SPF, or with DMARC at `p=none`, can be spoofed: anyone can send mail that appears to come from it, and receiving servers have been given no instruction to refuse. For most organisations this is a larger practical exposure than any missing response header, because it is the mechanism actually used against their customers and their finance team.

Domain registration. An expiry date approaching with auto-renewal off, or a registrar lock not set, is a route to losing the domain entirely. `dig` will not tell you this; the registration record will.

DNS itself. CAA records limit which certificate authorities may issue for the domain, which narrows one path to a fraudulent certificate. Their absence is not a vulnerability, and their presence is cheap.

Subdomains pointing at services no longer in use. A CNAME to a platform account that was closed can be claimed by whoever registers that name next, and the subdomain then serves someone else's content under your domain.

All four are observable from public records, all four are configuration rather than code, and all four sit outside what a scan of the website itself would ever report.