Free Website Security Checks: Malware, Security Headers, SSL, HSTS and GDPR in One Pass
CodexFuse Team · 2026-11-06T00:06:19.019Z · 18 min read min read
Free Website Security Checks: Malware, Security Headers, SSL, HSTS and GDPR in One Pass
A website security checker reads the security signals a public site shows to any outside visitor: whether it forces HTTPS, whether its certificate is healthy, which headers it sends, and whether anything on the homepage looks infected. This guide runs seven free checks in one pass, in the order that wastes the least time, using the free tools CodexFuse already publishes.
Each check below answers one question, and each one takes a few minutes. The first three catch the problems visitors actually hit: malware on the homepage, missing headers, and a broken certificate. The last four cover the things that bite later: HSTS, GDPR readiness, knowing which CMS you run, and the network around the site.
A website malware scanner is the right place to start, because an infected homepage makes every other result suspect, and our guide to VPS hosting explains the server side these outside-in checks can never see.
One warning up front, because it shapes how you should read every result in this guide: these are outside-in checks. They read what a visitor's browser sees. They cannot see your server files, your database, or your contracts, so a pass is a snapshot, not a verdict.
The rest of this guide shows you exactly where each check stops.
What Is a Website Security Checker?
A website security checker is a free online tool that reads the security signals a public website shows to any outside visitor. It opens one TLS connection, reads one HTTPS response, and reports what it finds: the certificate, the headers, and anything suspicious in the page. It does not log in, it does not test your forms, and it does not look at your code.
That outside-in view is both the strength and the limit. It is the same view your visitors and Google get, so it catches exactly the problems they hit. It is also blind to everything behind the login screen and everything on the server disk.
A checker can tell you a header is missing; it cannot tell you why your server never sent it.
Most free checkers specialise in one thing: malware, headers, certificates, or privacy. The one-pass method in this guide runs the specialists in sequence, so the seven results together cover the whole public surface. No single free tool does all of it, and CodexFuse does not offer a single combined website security checker tool — the pass below is the combination.
The One-Pass Order: Seven Checks in Sequence
Run the checks in this order. Malware first, because an infection poisons every other reading. Headers and certificate next, because they are the two things every visitor's browser checks.
HSTS after the certificate, because it only makes sense once HTTPS works. GDPR, CMS, and the network last, because they answer different questions from the first four.
- Scan the homepage for malware with the Website Malware Scanner.
- Read the seven security headers and take the score.
- Verify the SSL certificate, its chain, and its TLS versions.
- Confirm HSTS, then decide separately about preloading.
- Answer the 20-question GDPR self-assessment.
- Identify the CMS so you know what to patch.
- Map the subnet the site lives on, so the network makes sense.
| Check | Free tool | What it reads | Time |
|---|---|---|---|
| 1. Malware | Website Malware Scanner | Homepage HTML, HTTPS, HSTS, CSP | 1 minute |
| 2. Headers | Security Headers Checker | 7 response headers | 1 minute |
| 3. SSL | SSL Certificate Checker | Certificate, chain, TLS, grade | 2 minutes |
| 4. HSTS | HSTS Checker | HSTS header, max-age, preload | 1 minute |
| 5. GDPR | GDPR Compliance Checker | 20-question self-assessment | 10 minutes |
| 6. CMS | CMS Detector | Reference-table lookup | Under a minute |
| 7. Network | Subnet Calculator | IPv4 network math | 2 minutes |
The whole pass takes about twenty minutes, and the GDPR self-assessment is half of that. Everything else is a paste-the-URL, read-the-result check. Keep the results in one place — a note, a ticket, a spreadsheet — because the value of the pass is the comparison next time you run it.
Check 1: Scan Your Site for Malware
Start with the question "check my site for malware" — the exact phrase site owners type when something looks wrong. The Website Malware Scanner checks the public homepage only, in four parts: whether the site serves HTTPS, whether the page HTML carries known malicious patterns, how many scripts the page loads, and whether HSTS and Content-Security-Policy are present. The patterns it looks for include eval() calls, obfuscated document.write, fromCharCode tricks, suspicious iframes, and cryptominer signatures.
Injected pages often carry far more scripts than normal, so the script count is a signal on its own.
The result is one risk rating: low, medium, or high. A clean result means no common infection showed on the public surface, not that the server is clean. Hidden backdoors, database injections, and server-side malware need a server-side scan — ClamAV on your server, or a WordPress scanner such as Wordfence — plus the Security issues report in Google Search Console.
Treat this scan as a fast first pass, not the final word.
If the scan does flag something, change your hosting and CMS passwords first, restore from a backup made before the infection, run a server-side scan, and ask your host for help. If malware keeps returning after a clean restore, check the other sites on the same server: cross-site contamination is a common cause. Google Safe Browsing's site status page is the second opinion worth getting — it examines billions of URLs per day looking for unsafe websites, and a "No unsafe content found" result means Google sees no current threat at its last check.
That is a reputation check at a point in time, not proof the site is clean.
Check 2: Read Your Security Headers
A security headers scanner reads the headers your server sends with every page and grades what it finds. CodexFuse's Security Headers Checker examines seven headers and returns a weighted score, typically A+ down to F, with the most important headers counting the most. Our companion guide to the security headers checker explains the seven headers in full, including the exact fix value for each missing one.
| Header | What it stops |
|---|---|
| Strict-Transport-Security | Downgrade attacks; forces HTTPS on every visit |
| Content-Security-Policy | Cross-site scripting and injected content |
| X-Frame-Options | Clickjacking — your pages framed by attackers |
| X-Content-Type-Options | MIME sniffing — the browser guessing content types |
| Referrer-Policy | Leaking full page URLs to other sites |
| Permissions-Policy | Unwanted camera, microphone, or geolocation use |
| X-XSS-Protection | Legacy reflected-XSS filter in older browsers |
Two habits matter more than the grade. First, the strongest HSTS form is a max-age of at least one year plus includeSubDomains, so every subdomain is covered. Second, headers can vary by page, so a clean homepage does not prove a clean checkout — repeat the scan for the homepage, the login page, and any checkout or payment page.
Most sites fail this check. SecurityHeaders.com has run 409,948,008 scans, and 188,453,813 of them — about 46% — scored F, the lowest grade. Mozilla Observatory, which has assessed over 6.9 million websites through 47 million scans, averages about 6.8 scans per site, a sign that owners re-scan after fixing things.
Treat CSP with care: test it in report-only mode first, because enforcing an untested policy is one of the fastest ways to break a working site. A policy only limits damage; it does not remove the underlying flaw.
Headers are one layer of defence in depth, not a complete security strategy. They limit what a browser will do with attacker content, but they do not patch vulnerabilities, fix weak passwords, or replace a firewall. They are also not a direct ranking factor, though keeping visitors on the secure version and avoiding browser warnings supports SEO.
Check 3: Verify the SSL Certificate
An SSL certificate check takes five things and checks each one separately: the expiry date, the domain match, the certificate chain, the issuer's trust, and the TLS versions the server offers. Any one of them can fail on its own, and the failure you see depends on which one broke. Our SSL certificate checker walks through all five, and the live HTTPS request also records the response time in milliseconds.
| What is verified | What a failure looks like |
|---|---|
| Expiry date | Browser warning; the site stops loading for visitors |
| Domain match | Certificate issued for a different name; browsers refuse it |
| Certificate chain | Some browsers fill the gap from cache, others warn — the site looks fine to you and broken to a customer |
| Issuer trust | Self-signed or unknown issuer; browsers do not trust it |
| TLS support | Old TLS versions offered; modern browsers refuse the connection |
SSL is the older name for the protocol that encrypts HTTPS traffic; TLS is its modern successor. Your server should offer TLS 1.2 and 1.3 and nothing older: TLS 1.0 and 1.1 were formally deprecated by the IETF in March 2021, and every major browser removed them in 2020. TLS 1.3, standardised in August 2018, completes its handshake in one round trip instead of two and requires forward secrecy.
TLS 1.2 is still secure when configured correctly, with ECDHE key exchange and AEAD ciphers.
The checker also shows the SSL Labs grade, from A+ to F, but only when SSL Labs has previously analysed the domain — the grade comes from cached data up to 24 hours old, while the HTTPS status and response time are measured live every time. The current SSL Labs rating guide (version 2009r, dated 16 May 2025) caps servers without TLS 1.3 at A-, so the grade now rewards the current protocol directly.
Certificates are getting shorter. Under CA/Browser Forum Ballot SC-081v3, the maximum lifetime of a publicly trusted TLS certificate falls from 398 days to 200 days for certificates issued from 15 March 2026, then to 100 days from 15 March 2027 and 47 days from 15 March 2029 — a cut of 198 days, or about 49.7%, at the first step. The rule binds certificate authorities, not site owners directly, but it means renewals and automation matter more every year.
Check your certificate at least once a month, again after any hosting, domain, or server change, 30 days before expiry, and right after renewal.
Check 4: Confirm HSTS — and Think Twice Before Preloading
An HSTS check reads the Strict-Transport-Security header your server sends and parses it, not just detects it: the max-age, whether includeSubDomains is set, and whether the preload flag is present. The strongest form is a max-age of at least one year — 31,536,000 seconds — plus includeSubDomains. HSTS tells browsers to use HTTPS only, which closes the gap where a visitor's first request goes out over plain HTTP.
| Preload requirement | What it takes |
|---|---|
| Valid certificate | The site serves a valid certificate |
| HTTP redirects to HTTPS | Plain HTTP on the same host redirects to HTTPS |
| All subdomains on HTTPS | Every subdomain, including www if it has a DNS record, serves HTTPS |
| HSTS header on the base domain | max-age of at least 31,536,000 seconds, with includeSubDomains and preload |
Preloading is the step after HSTS: the domain is baked into Chrome's preload list, which Firefox, Safari, and Edge base their own lists on, so browsers know the policy before the first visit. It is also the step to think twice about. HSTS preloading is not recommended as a default — the preload list's own guidance says so — because inclusion cannot easily be undone: removal takes months to reach users through a Chrome update.
Ramp the max-age up in stages first, from five minutes to a week to a month, checking for breakage at each stage, and only then consider the preload flag. A two-year max-age, 63,072,000 seconds, is a common steady state before anyone talks about preloading.
Check 5: Test GDPR Readiness
A GDPR compliance checker cannot read your contracts or judge your lawful basis, so the honest version of this check is a self-assessment. CodexFuse's GDPR Compliance Checker asks 20 questions across five categories — lawful basis and consent (4), data subject rights (5), security and breach response (4), documentation and accountability (4), and third parties and transfers (3) — and turns the answers into a score with fixes. One "no" in any category is a task to fix.
Our GDPR compliance checker guide explains the five categories in full. A checker flags common issues and gives you an honest baseline, but it cannot confirm legal compliance. No automated tool can read your contracts, judge your lawful basis, or decide whether your consent flow holds up in a dispute.
Treat the result as a prioritised to-do list, not a verdict.
| What an external GDPR check can see | What it cannot see |
|---|---|
| Cookie banner and reject-all option | Whether trackers fire before consent |
| Privacy policy presence and coverage | Server-side data handling and vendor contracts |
| Third-party scripts in the page source | Trackers injected by JavaScript after load |
| Cookies set, and whether before consent | Lawful-basis assessments and DPIAs |
| HTTPS, TLS, and security headers | Pages behind a login |
Two rules keep the wording honest. First, a banner's presence does not confirm that consent is valid: consent must be freely given, specific, informed, and unambiguous, and obtained before processing. Second, a generated policy is a draft to review, not a finished legal document — the generator cannot see your real data practices, so anything you leave out, the draft leaves out.
GDPR applies to any business handling personal data of people in the EU or UK, whatever its size: a one-person shop with a contact form is in scope. Most sites need both a cookie banner and a privacy policy, and a banner without a linked policy leaves visitors without the information they were promised. Re-check at least once a year, and after any redesign, new form, new analytics tool, or new processor.
Check 6: Identify Your CMS So You Know What to Patch
A CMS detector identifies the content management system a website runs on, which tells you what to patch and what to watch. The CodexFuse CMS Detector is a reference-table lookup, not a live scan: it holds a built-in table of 16 well-known sites and returns the CMS for those hostnames — WordPress for wordpress.com, Shopify for shopify.com, Wix, Squarespace, Drupal, Joomla, and Contentful for cloudflare.com — and "None" for nine custom-built sites such as google.com and github.com. Any other hostname returns "Not found", which means the hostname is not in the table, not that the site has no CMS.
For an arbitrary site, use a live detector that reads the site's HTML, meta generator tags, and script paths.
Knowing the platform matters because patching is platform-specific: a WordPress site needs its core, themes, and plugins updated on one schedule, a Shopify store leans on the platform's own updates, and a custom build puts every update on you. Run this check before you plan maintenance, not after something breaks. It is the weakest check in this pass — it identifies the platform, it does not judge its security — and it earns its place by making the other six checks actionable.
Check 7: Map the Network Around the Site
The last check is not a security verdict at all: it is the network math that makes the other results readable. The Subnet Calculator splits an IPv4 network into equal subnets — enter a network address and a base prefix, pick a longer prefix, and get the subnet count, the size, and each subnet's network, broadcast, and usable range. Splitting 192.168.0.0/16 into /24 networks gives 256 subnets of 256 addresses each, 65,536 addresses in total, because each extra prefix bit doubles the count: 2 raised to 8 is 256.
Why does this belong in a security pass? Because the network around a site is where the next checks happen: which addresses the site can reach, which subnets hold the database, and whether the admin panel sits on a network anything can reach. A calculator does not read your network — it does the arithmetic so you can plan the segmentation.
Keep it next to the other six checks, not instead of them.
What a Clean Result Actually Means
Every check in this pass can come back clean, and every clean result means the same narrow thing: nothing visible from outside, right now, on the pages tested. A clean headers scan does not cover the checkout page you did not test. A valid certificate does not mean the site behind it is safe.
A "No unsafe content found" result from Safe Browsing means Google sees no current threat at its last check — and Google's own page says site safety can change over time.
So read the seven results as a snapshot and a to-do list. Fix the red items in the order of this pass, re-run the checks that changed, and keep the server-side work on a separate list: server scans, password rotation, backups, and the Search Console Security issues report. The outside-in pass tells you what visitors see.
The inside work is what keeps it that way.
Free Checks vs a Paid Security Scan
Free checks answer the question "what does the outside see?" A paid scan answers the question "what is wrong inside?" The difference is access: a paid scanner or a security audit logs in, reads server files, tests forms, and probes for vulnerabilities the free tools cannot reach. It also costs money and needs authorisation — never run an intrusive scan against a site you do not own or have written permission to test.
Hire the paid scan when the free pass keeps finding the same problem, when the site takes payments or stores customer data, after any confirmed infection, or before a launch that carries real traffic. For a small brochure site with no login and no payments, the free pass plus a server-side scan from your host is usually enough. The free checks stay useful either way: they are the fastest way to confirm a fix worked, and the cheapest way to catch a regression.
How Often to Re-Run the Seven Checks
Security checks decay. Certificates expire, headers disappear in a deploy, a new plugin adds a tracker, and a redesign drops the cookie banner. The pass is only worth doing if it repeats, so put each check on a schedule and tie it to the events that break it.
| Check | How often | Re-run trigger |
|---|---|---|
| Malware scan | Weekly | Any odd behaviour, traffic drop, or warning |
| Security headers | Monthly | Any deploy, server, or CDN change |
| SSL certificate | Monthly | 30 days before expiry; after renewal |
| HSTS | After any change | Any header, domain, or hosting change |
| GDPR self-assessment | Yearly | Redesign, new form, new analytics, new processor |
| CMS identification | After any change | Migration, rebuild, or platform switch |
| Subnet map | After any change | Network or hosting move |
The cheapest cadence is the one tied to events: run the headers and certificate checks after every deploy, the malware scan every week, and the GDPR assessment once a year. A check that only runs when something already looks wrong is not a check at all.
Sources
Every fact in this article comes from a source fetched on 6 November 2026. CodexFuse's own tool pages and sibling blog posts are the primary source for what the tools do; Mozilla Observatory, securityheaders.com, SSL Labs, hstspreload.org, and the CA/Browser Forum documents are the primary sources for the standards; secondary sources are labelled where a primary page could not be fetched.
- CodexFuse Website Malware Scanner — https://codexfuse.dev/tools/website-malware-scanner
- CodexFuse CMS Detector — https://codexfuse.dev/tools/cms-detector
- CodexFuse Security Headers Checker — https://codexfuse.dev/tools/security-headers-checker
- CodexFuse SSL Certificate Checker — https://codexfuse.dev/tools/ssl-certificate-checker
- CodexFuse HSTS Checker — https://codexfuse.dev/tools/hsts-checker
- CodexFuse GDPR Compliance Checker — https://codexfuse.dev/tools/gdpr-compliance-checker
- CodexFuse Subnet Calculator — https://codexfuse.dev/tools/subnet-calculator
- Security headers: seven headers, scoring, and fixes — https://codexfuse.dev/blog/security-headers-checker-analyze-http-security-headers-get-a-score
- SSL certificate: five checks and monthly cadence — https://codexfuse.dev/blog/ssl-certificate-checker-verify-https-ssl-status-online
- GDPR: 20-question self-assessment — https://codexfuse.dev/blog/gdpr-compliance-checker-test-your-website-for-gdpr-compliance-free
- Privacy policy: draft, not a legal document — https://codexfuse.dev/blog/privacy-policy-generator-create-a-gdpr-ccpa-compliant-privacy-policy-free
- Mozilla Observatory — https://observatory.mozilla.org/
- securityheaders.com — https://securityheaders.com/
- Qualys SSL Labs — https://www.ssllabs.com/ssltest/
- HSTS preload list — https://hstspreload.org/
- Google Safe Browsing site status — https://transparencyreport.google.com/safe-browsing/search
- CA/Browser Forum certificate-lifetime schedule — https://www.sslclock.com/47-day-certificates (primary ballot page not fetched this run; schedule corroborated by six independent sources quoting Baseline Requirements v2.3.1)
- Sucuri SiteCheck limits — https://www.techradar.com/reviews/sucuri-sitecheck (sitecheck.sucuri.net blocked in this environment; claims via TechRadar, Cloudways, and veravix search results)
- GDPR external-check limits — https://inventivehq.com/blog/what-does-a-gdpr-compliance-checker-scan-for-on-websites and https://www.auditzo.com/blog/gdpr-audit-checklist-eu-websites/
- TLS 1.2 vs 1.3 status in 2026 — https://www.tr7.uk/en/resources/blog/tls-13-migration-2026
Frequently Asked Questions
Is a free website security checker enough to keep my site safe?
No. A free checker reads the public surface — the certificate, the headers, the homepage. It cannot see server files, databases, or login-protected pages, so pair it with a server-side scan, strong passwords, backups, and the Search Console Security issues report.
The free pass finds the visible problems fast; the inside work keeps the site safe.
Does a clean malware scan mean my site has no malware?
No. A clean result means no common infection showed on the public homepage at the time of the scan. Hidden backdoors, database injections, and server-side malware need a server-side scan such as ClamAV or Wordfence.
How do I check HSTS on my website?
Run a security headers scan and read the Strict-Transport-Security header: look for a max-age of at least 31,536,000 seconds and includeSubDomains. The HSTS Checker parses the header and reports the max-age and preload status directly. Do not add the preload flag until the max-age has ramped up in stages and nothing has broken.
Does a high GDPR score mean my site is legally compliant?
No. A high score means you answered a 20-question self-assessment well. Legal compliance depends on your real practices, contracts, and consent flows — things no automated checker can judge.
Treat the score as a prioritised to-do list, not a verdict.
How often should I check my SSL certificate?
At least once a month, again 30 days before it expires, and right after any renewal or hosting change. Certificates are also getting shorter — the maximum is 200 days for newly issued certificates in 2026, falling to 100 days in 2027 — so automation matters more every year.
