// blog
How to Check Your Website's Security for Free (and Fix What It Finds)
Automated attacks start with a quick look at what every site shows the public: whether HTTPS is set up properly, which security headers are missing, whether cookies are protected, whether private files like .env or .git can be downloaded, and whether anyone can send email as your domain. You can see exactly the same thing with the free website security checker: enter your address and you get a grade and a plain-English fix for each problem, usually a one-line change in your server or DNS settings.
Many attacks on websites don’t begin with a person. They begin with a script that visits site after site and notes which ones look easy: an expired certificate, an old server version on display, a .env file anyone can download, no rules about which scripts a page may run. The sites that look easy get a closer look.
The good news is that this first check only uses what your site shows to the whole world. That means you can run it yourself, see what they see, and fix it before anyone else notices.
Check your site in about 20 seconds
I built a free website security checker for exactly this. Enter your address; there’s no account and no email address needed. It looks at your site from the outside, the way a browser and a mail server would, and gives you a grade from A to F with a plain-English fix under every problem. You can copy the report or have it emailed, to pass on to whoever runs your site.
It never tries to break in: no password guessing, no form submissions, no port scans. It makes a handful of ordinary requests and reads your public DNS records, and nothing about your site is stored.
What it checks, and why each one matters
1. Encryption: HTTPS and the certificate
Whether your site works over HTTPS, whether the certificate is valid and trusted, how many days it has left, and whether visitors who type your address without https:// get sent to the secure version. It also checks for HSTS (Strict-Transport-Security), the header that tells browsers to only ever use HTTPS for your site, so a visitor on public Wi-Fi can’t be quietly downgraded to an unencrypted connection.
A broken certificate gets an automatic F, because browsers show visitors a full-page warning instead of your site.
2. Browser protection: the security headers
A few short response headers turn on protections that are built into every modern browser:
- Content-Security-Policy lists where scripts may come from, so code an attacker manages to inject doesn’t run.
- X-Frame-Options (or CSP
frame-ancestors) stops other sites from loading yours in an invisible frame and tricking people into clicking (clickjacking). - X-Content-Type-Options: nosniff stops browsers from treating an uploaded file as a script.
- Referrer-Policy and Permissions-Policy limit what other sites learn about your pages and which device features (camera, microphone, location) your pages may use.
The OWASP HTTP Headers Cheat Sheet lists the recommended values for each, and the checker quotes them in its fixes.
3. Cookies
If your home page sets cookies, each should be marked Secure (only sent over HTTPS), HttpOnly (scripts can’t read it) and SameSite (not sent along with requests from other sites). A session cookie without them is much easier to steal.
4. Exposed files and information
Two files cause real damage when a web server hands them out by accident: a .git folder, which can give away a site’s entire source code and history, and an .env file, which usually holds passwords and API keys. Automated scanners routinely look for both. The checker requests exactly those two addresses and only counts them as exposed when the content really looks like a git or env file, so a site that answers every address with its home page doesn’t get a false alarm. Either one means an automatic F, and the fix starts with changing every password in the file.
It also flags servers that announce their exact software version (Server: Apache/2.4.41, X-Powered-By: PHP/7.4.3, a WordPress version in the page), which tells attackers which known weaknesses to try.
5. Page content
Files loaded over plain http:// on a secure page (mixed content), which browsers block or warn about, and scripts loaded from other sites without an integrity check. That last one is often unavoidable (analytics, chat widgets) but worth knowing: if one of those sites is hacked, so is yours.
6. Email spoofing
This one surprises people: your domain’s DNS records decide whether scammers can send email that looks like it came from you. SPF lists the servers allowed to send your mail (RFC 7208), DKIM signs it, and DMARC tells Gmail, Outlook and Yahoo what to do with mail that fails (RFC 7489). A domain without DMARC, or with p=none, still lets fake mail through.
What I found when I checked my own site
I ran the checker on this site the day I built it. It scored an A, but not a perfect one, and the findings were real:
- The web server announced its exact version in every response. One line fixed it (
server_tokens off;in nginx). - There was no
security.txt, the small file (RFC 9116) that tells people who find a problem how to reach you. I added one. - DMARC was set to
p=none, so fake email using my domain was still being delivered. Before tightening it, I read the DMARC report Yahoo had sent: my real mail passed both SPF and DKIM, so moving top=quarantinewas safe. - There was no CAA record, which names the only certificate authority allowed to issue certificates for the domain. One DNS record.
None of these took more than a few minutes. After fixing them, the site scores 100 out of 100, and the checker now shows a clean report for it.
The quick fixes for the most common problems
Most findings are one line in your web server’s configuration (nginx, Apache, IIS), your hosting control panel, or your CDN’s settings:
| Finding | The usual fix |
|---|---|
| No HTTPS redirect | Redirect every http:// request to https:// with a permanent (301) redirect |
| No HSTS | Strict-Transport-Security: max-age=63072000; includeSubDomains (only once every subdomain works over HTTPS) |
| No clickjacking protection | X-Frame-Options: SAMEORIGIN, or frame-ancestors 'self' in your CSP |
| No nosniff | X-Content-Type-Options: nosniff |
| Version banner | Hide it (server_tokens off in nginx, ServerTokens Prod in Apache, expose_php = Off in PHP) and keep the software updated |
| No SPF or DMARC | Add the TXT records your email provider gives you; for DMARC start with p=none, read the reports, then move to p=quarantine |
A Content-Security-Policy takes more care than the others, because a strict policy can break scripts your site relies on. Start with Content-Security-Policy-Report-Only, see what it would block, and only then switch it on.
What a checker can’t tell you
A clean result means the basics attackers check first are in place. It doesn’t mean the site can’t be hacked: an outside check can’t see an outdated plugin, a weak admin password, or a bug in your own code. Those need a security review or penetration test by someone you’ve given permission to test the site.
But the basics are where most automated attacks start, and they’re the cheapest to fix. Run the free check on your site, send the report to whoever looks after it, and run it again after the changes. If you’d rather have someone go through the findings with you, get in touch.