Blog · Website and TLS
15 external website checks any business can run today
You do not need a penetration test to find out whether your certificate covers your own hostname or whether plain HTTP still works. You need fifteen minutes and a terminal.
The short version
- These checks cover the connection and the response, not the application. A pass here is not a security guarantee.
- Most findings are configuration, which means most fixes are one deploy and one DNS edit.
- Run them quarterly. The value is in the diff, not the first report.
- Only run them against domains you own or are authorised to test — a scan is still a scan.
There is a useful dividing line in website security work. On one side: what an anonymous visitor's browser can observe in a single request. On the other: everything that requires an account, a payload or a code review. This page stays strictly on the first side, because that side is free, safe to repeat, and catches the mistakes that were never a decision.
Every check below works against your own site only. If you are checking on behalf of a client, get it in writing first — see responsible use.
Connection and certificate: checks 1 to 4
Start with one command, which fetches the response headers and follows redirects:
curl -sSIL https://www.yourdomain.com | head -40| # | Check | How to verify | What good looks like |
|---|---|---|---|
| 1 | HTTP redirects to HTTPS | curl -sI http://yourdomain.com | A 301 or 308 directly to the HTTPS URL, keeping the path |
| 2 | Certificate is valid and current | Click the padlock, or openssl s_client -connect yourdomain.com:443 -servername yourdomain.com | Trusted chain, expiry well in the future, no hostname mismatch |
| 3 | Both hostnames are covered | Open the bare domain and the www version | Both work, both serve the certificate, neither throws a warning |
| 4 | Only modern TLS | openssl s_client -tls1_1 -connect yourdomain.com:443 | The handshake fails; TLS 1.2 and 1.3 succeed |
Check 1 has a subtlety worth knowing: a redirect that goes to the homepage instead of the requested path is technically working and practically broken, because it silently rewrites every deep link. Check 4 fails loudly and harmlessly — an old protocol being refused is the expected result, not an error worth investigating.
Response headers: checks 5 to 11
These come from the same curl -sI output. Headers are cheap to add and easy to
forget, and their absence is one of the most common findings in any external assessment.
| # | Header | What to look for | Why it matters |
|---|---|---|---|
| 5 | Strict-Transport-Security | max-age=31536000; includeSubDomains | Tells browsers to refuse plain HTTP for your domain after the first visit |
| 6 | Content-Security-Policy | At minimum default-src 'self'; object-src 'none' | Limits where scripts and embeds can load from, which is what turns an injected string into an executed one |
| 7 | X-Content-Type-Options | nosniff | Stops browsers guessing a file's type and executing an upload as script |
| 8 | Framing protection | frame-ancestors 'none' in CSP, or X-Frame-Options: DENY | Prevents your pages being embedded in a clickjacking overlay |
| 9 | Referrer-Policy | strict-origin-when-cross-origin or stricter | Stops full URLs leaking to third parties through the Referer header |
| 10 | Permissions-Policy | Camera, microphone and geolocation denied unless needed | Limits what an embedded or injected script can request |
| 11 | Version disclosure | No Server: Apache/2.4.x or X-Powered-By: PHP/8.x | Removes a free hint about which vulnerabilities to try |
Two honest caveats. A strict CSP will break a site that loads third-party widgets, so add it
in report-only mode first and read the violations. And HSTS with a long max-age is
effectively permanent for returning visitors — if any subdomain still only serves HTTP,
add includeSubDomains only after fixing it.
Content and exposure: checks 12 to 15
These need a browser rather than a single request, and they are the ones most likely to find something real.
- Mixed content. Open DevTools, load the console, and look for warnings about insecure resources. A page served over HTTPS that pulls in a script over HTTP is only half-protected, and the browser will often block it outright.
- Files that should not be public. Try a handful of paths that are common
deployment accidents:
/.git/config,/.env,/backup.sql,/.DS_Store. You are looking for a 404. Anything else deserves a conversation with whoever deploys your site. - Directory listing. Visit an image or upload directory without a filename. If you get an index of files, the web server is configured to list them, and every file in it is now public.
- Dangling subdomains. Enumerate the subdomains you know about —
mail,blog,shop,staging,dev— and check each resolves. Then check where. A CNAME pointing at a service you closed is the one finding here that can fully compromise your domain's reputation without touching your server.
One more that costs nothing while you are in DevTools: look at the cookies on your login
page. Secure, HttpOnly and SameSite should all be set.
A session cookie without them is a real weakness, not a style preference.
What these fifteen cannot tell you
Everything here is a property of the connection and the response. None of it tests whether your login form can be bypassed, whether an old plugin has a known vulnerability, whether one customer can read another's invoice by changing a number in the URL, or whether your admin panel is protected by anything other than obscurity.
That is not a flaw in the list; it is the boundary between configuration review and application testing. A clean sheet here means "the outside looks properly wired", which is worth knowing and considerably less than "we are secure". The reference article on misconfigurations visible from outside covers the same ground with more detail on each header, and the limitations page states the boundary in the same terms.
The fifteen checks map closely onto the controls SMB Scanner Lite automates — TLS version, certificate validity, cipher suites, redirect path and the five header checks. Running them by hand is a good way to understand what an automated result is actually reporting.
What SMB Scanner Lite checks here
These are the controls from this area that the assessment evaluates from outside, without credentials and without touching anything private. Each one returns a status and, for every conclusive result, the record, header or handshake that produced it.
| Control | What is evaluated |
|---|---|
| TLS protocol versions | Whether obsolete protocols are still negotiable on the public endpoint. |
| Certificate validity | Expiry, chain and whether the hostname is actually covered. |
| Cipher suites | Whether forward secrecy is available and legacy suites are disabled. |
| HTTPS redirect path | Whether plain HTTP redirects to HTTPS, and whether it leaks the path first. |
| Security headers | HSTS, CSP, framing and MIME-sniffing protection, referrer and permissions policy. |
Only assess domains you own or are authorised to test — see responsible use. The published recorded assessment shows how a result and its evidence appear in a report, and the control catalog lists all 22 controls with their weights. Reference detail for this topic lives in Six security misconfigurations that are visible from outside.