Free website security checkers: what they test, what they can't see, and whether the result counts as evidence

Yes, run one. A free checker costs nothing and takes a few minutes. It tells you true things about the outside of your site: whether HTTPS is set up properly, whether the security headers browsers rely on are switched on, whether your domain is on a blocklist or serving known malware, and whether the site advertises out-of-date software. If it flags something, that is a real problem, and often a cheap one to fix.

What it can’t tell you is what happens after someone logs in. For a business with customer accounts, that is where the personal information sits: the portal, the order history, the client file. A clean grade is a valid data point about the front of your web application. It does not verify the safeguards around your customers’ data, and you shouldn’t file it as though it does.

What the free checkers actually test

Three free tools make good examples, and each one is candid in its documentation about its scope.

SSL Labs tests your server’s TLS configuration, meaning the encryption between a visitor’s browser and your site. Its SSL Server Rating Guide builds the grade from three categories: protocol support and key exchange at 30% each, and cipher strength at 40%. Certificate problems can override the result. The whole score is about the connection. The application on the other end doesn’t come into it.

Mozilla’s HTTP Observatory reads the headers your site sends back. Its FAQ says it tests for preventative measures against cross-site scripting, manipulator-in-the-middle attacks, cross-domain information leakage, insecure cookies, content delivery network compromises and improperly issued certificates.

Sucuri SiteCheck covers blocklists and malware. Sucuri’s page says it looks for “known malware, viruses, blacklisting status, website errors, out-of-date software, and malicious code”.

Why they cannot see past the login

The limit comes from how these tools work. They are passive and unauthenticated. You give them a web address and nothing else, and they grade what your site sends to an anonymous visitor. They hold no password, so they cannot act as a user. They have good reason to stay passive, too: Mozilla’s FAQ notes that “anyone can choose to scan any domain, and the scan history for each domain is public.”

The documentation says as much. The SSL Labs guide limits itself to “configuration problems whose presence can be determined remotely and without manual assessment”. It says web-application checks are “non-trivial to perform in an automated fashion, and this version of the guide does not attempt to do it.” Sucuri’s page is blunter: “Since the remote scanner only has access to what’s visible on the browser level, it will not detect anything on the server-side.” And Mozilla’s FAQ is plain about what the Observatory leaves out:

“it does not test for outdated software versions, SQL injection vulnerabilities, vulnerable content management system plugins, improper creation or storage of passwords, and more.”

The flaw OWASP finds most often is mainly about what users can reach once they’re logged in. OWASP’s Top 10:2025 ranks broken access control first, with 1,839,701 occurrences in its contributed data, and it found some form of the flaw in every application tested. In OWASP’s words, access control means users “cannot act outside of their intended permissions”. A typical failure is one logged-in customer opening another customer’s records. An anonymous checker can’t test most of that, because testing it means being a user.

Where section 19 comes in, and where the scan stops

Section 19 of POPIA requires you to guard personal information against, among other things, “unlawful access to or processing of personal information”. To do that, you must identify the reasonably foreseeable risks, put safeguards in place, keep them updated as risks change and, in the Act’s words, “regularly verify that the safeguards are effectively implemented”.

A dated SSL Labs or Observatory report is legitimate evidence for that verify duty, but only for one part of the system: the external face of your web application. It shows that the connection is encrypted sensibly and that the browser-side protections are on. It does not verify the safeguards around the data itself, such as who can read a record once signed in or how passwords are stored. And it says nothing about the other three duties. File it in your POPIA §19 register as one line with a narrow label, not as the whole answer.

Can a bank or insurer use the report?

Partly. It works as a record of the outside of your site. It doesn’t work as proof that the application protects customer data. The report comes from a public tool rather than from you, and a reviewer can re-run it in minutes. But if the questionnaire asks whether the application has been tested, a header grade doesn’t answer that.

A few habits make the result worth keeping. First, run the checks against the exact address your customers use. Second, save the full report with its date, not just the letter grade. Third, fix what it flags, re-run the check and keep both results, because a before-and-after pair is what “verify” looks like on paper. Fourth, write down in plain words what the check did not cover: “External TLS, headers and blocklist status only. Logged-in functionality not tested.” That line keeps the record honest.

When a free checker is the whole answer. If your site is a brochure with a contact form, with no customer logins and no payments on your own pages, there is no “after login” to test. In that case, a free checker run on a schedule you write down, plus keeping your CMS, plugins and hosting patched, may be all the website needs. We’d tell you not to buy a scan. The personal information from that form still needs protecting wherever it lands, whether that’s an inbox or a CRM, but that is a question about those systems, not about the website.

Things change once customers log in and their data sits behind that login. That is the gap Deep Scan is for, and it has limits of its own. It runs only after we confirm you own the domain and agree a written scope and authorisation, which a free tool has no way to ask for. By default it is external and black-box. Two test logins add checks for one user reaching another user’s records and for forged login tokens. A full role-by-role authorisation matrix and business-logic flaws are outside its scope. Where a standard requires a manual penetration test, that is what you need, and we will say so.

If you’re not sure which side of that line your site falls on, send us the domain. We’ll tell you honestly whether it needs Deep Scan, a manual test, or none of ours.