Most websites are not compromised by a determined attacker picking a target. They are found by a script that sweeps thousands of domains looking for the same handful of mistakes: an expired certificate, a missing header, a forgotten backup file sitting in the web root.
This scan looks for exactly those things from the outside, the way an attacker would. It reads your certificate, checks the six security headers browsers actually act on, and tests whether files like <code>.git/config</code> or <code>.env</code> can be downloaded by anyone who guesses the URL.
Scan my site- SSL certificate validity and expiry
- HSTS, CSP and four other security headers
- Publicly readable .git, .env and backup files
- Directory listing and version disclosure
- Mixed content and cookie flags
What are security headers and do they matter?
They are instructions your server sends with every page telling the browser how to behave. Strict-Transport-Security forces HTTPS so a visitor cannot be downgraded to plain HTTP on dodgy wifi. Content-Security-Policy restricts where scripts may load from, which is the single strongest defence against injected code. X-Content-Type-Options and clickjacking protection close two more common attack routes. They cost nothing, they are a configuration change rather than a rebuild, and most Australian small business sites are missing several.
Why is a .env or .git file such a big deal?
Because those files usually contain the keys to everything. A .env file typically holds your database password, mail credentials and API keys in plain text. An exposed .git directory lets somebody reconstruct your entire source code, including any secrets ever committed to it. Both get there by accident, deployed along with everything else, and both are trivially discoverable by automated scanners. If this scan finds one, treat it as urgent and rotate the credentials.
My site has an SSL certificate, is that enough?
No, though it is the right start. A certificate encrypts the connection, it does not secure the site. This scan also checks whether the certificate actually validates, whether it covers the hostname people type, and how many days remain before it expires. Expiry is the most common self-inflicted outage in small business: nobody notices until every visitor gets a full-page browser warning and enquiries stop dead.
Does this replace a penetration test?
It does not, and we would not claim otherwise. This is an external configuration review. It cannot see your server, your passwords, your plugin versions or your database, and it does not attempt anything intrusive. What it does is close the doors that get found by automated sweeps, which is how the overwhelming majority of small business sites actually get compromised. A proper penetration test is a different, much deeper exercise.
What do I do if the scan finds something?
Work in this order. Anything marked as needing fixing that involves an exposed file: delete it now and change every credential it contained. Then the certificate, because that one takes the site down. Then the headers, which are usually a few lines in your server config or a plugin setting. If the site has already been compromised, cleaning the files is only half the job, you also have to find and close the way in, or it happens again within weeks.
The headers browsers actually act on
All six are configuration, not code. Most sites are missing at least three.
| Header | What it prevents | Priority |
|---|---|---|
| Strict-Transport-Security | Downgrade to insecure HTTP | High |
| Content-Security-Policy | Injected and malicious scripts | High |
| X-Content-Type-Options | Browsers guessing file types | Medium |
| X-Frame-Options | Clickjacking via hidden frames | Medium |
| Referrer-Policy | Leaking URLs to third parties | Low |
| Permissions-Policy | Unwanted camera, mic and location access | Low |
How to lock down a small business website
-
1
Scan it first
Get the external view before changing anything, so you can prove the fixes worked.
-
2
Remove anything that should not be public
Delete .env, .git, backups and phpinfo from the web root, then rotate every credential they held.
-
3
Fix the certificate and force HTTPS
Renew, enable auto-renewal, and 301 redirect all HTTP traffic.
-
4
Add the security headers
Start with HSTS and a report-only Content-Security-Policy, then tighten.
-
5
Update everything and cut down the surface
Patch your CMS, theme and plugins, and delete the ones nobody uses.
-
6
Set up backups and monitoring
Off-site backups you have actually restored from, plus uptime and malware monitoring.
Fair questions.
Is it legal to scan a website I do not own?
This tool only requests public pages, exactly as a browser or search engine does. It does not attempt to log in, exploit anything or send unusual traffic. That is ordinary web use. Anything genuinely intrusive would need the owner's permission, which is why we do not do it.
Will this scan set off my security software?
It might appear in your logs as a handful of requests, including a few for files that do not exist. That is normal and harmless. It is a read-only check with no attack traffic.
My site scored well. Am I safe?
Safer, not safe. A good score means the common external doors are closed. It says nothing about weak passwords, outdated plugins, your hosting account security or whether someone already has access. Security is ongoing rather than a certificate.
What is the single most important fix?
Anything publicly exposed that contains credentials, then certificate expiry. Both are quick, and both have consequences far out of proportion to the effort.
Do I need a Content-Security-Policy on a simple brochure site?
It is the most valuable header and also the fiddliest to get right, because a badly written policy can break your own scripts. Start in report-only mode. For a simple site it is usually an afternoon.
My site was already hacked. Will this find the malware?
Not reliably. This checks configuration, not file integrity. A compromised site needs a full file and database scan, a clean restore, credential rotation and the entry point closed, which is what our recovery service does.
Does hosting affect any of this?
Considerably. Good managed hosts set most of these headers by default, patch quickly and keep tested backups. Cheap oversold shared hosting typically does none of it and puts you on an IP with hundreds of unknown neighbours.
How often should I run this?
Quarterly, and after any migration, redesign or plugin overhaul. Certificates and configurations drift, and a change that fixed one thing often quietly undoes another.
Defaced, redirecting to another site, or flagged by Google? We clean it, restore it, clear the warning and lock it down.