Check Your Website Security Online

You can build a useful external security baseline for your own website in about an hour with free tools, across four areas. First, certificate and encryption: the SSL Server Test from Qualys SSL Labs gives you a grade for the hostname you enter; every relevant variant such as the root domain and www needs its own check. Second, the security headers, the instructions your server sends along to every browser: Mozilla's HTTP Observatory checks them, starts at 100 points and deducts for every missing setting. Third, outdated software and known vulnerabilities: Sucuri SiteCheck spots externally visible outdated systems and blocklist entries, and for WordPress the WPScan vulnerability database comes on top. Fourth, externally reachable admin areas, the part no tool does for you: in a logged-out browser window, you check what is reachable and whether that exposure is intended and protected. Before any of that stands a boundary that is taken for granted among professionals: you test your own website, or one you have written permission for, and nothing else. And what these tests fundamentally cannot see is the most honest part of this article.

In my own business this work is done by an AI employee who does not stop at a grade, but delivers evidence, a severity rating and a repair proposal for every finding. More on that below. If you are working on your site anyway, these four checks belong in the same pass as a rebuild of an existing site, because certificates, redirects and headers all shift with every relaunch.

The boundary that comes before any test

A security test sends requests to someone else's system, even when it looks harmless. That is why people who do this for a living follow one simple rule: you test your own system, or one you hold written permission for from the operator. The permission should name the date, scope, allowed methods, time window, emergency contact and handling of any data found, and you should also check the hoster's or platform's terms. German criminal law is narrower than a blanket ban: § 202a concerns specially protected data and overcoming access protection, while § 202b concerns intercepting non-public data transmissions with technical means. Merely opening publicly offered information or requesting its headers does not normally meet those elements. Active tests on third-party systems can still create criminal, contractual and operational risks, which is why written permission comes first. This is not legal advice.

In practice that means: permission exists before the first active test request, not afterwards, and it names the exact system in question, because permission for the main domain does not automatically cover a test environment on a secondary address. If your site is hosted by a service provider, clarify what the provider and platform terms allow. It is the working rule under which no test in my business starts without written approval. The four tools below stay at the external, logged-out layer, but that does not replace a defined scope.

Step 1: Certificate and encryption

The SSL Server Test from Qualys SSL Labs is free and only needs your address. It works through the supported protocols and cipher suites and returns a grade. By default the result lands on a public board, but there is an option to suppress that. I always tick it. The grade comes from three areas: protocol support at 30 percent, key exchange at 30 percent, cipher strength at 40 percent. Zero points in any one area means an immediate F.

Three things you check by hand as well, because they go wrong more often in daily life than the encryption itself. Open your site once with and once without www: many certificates only cover one variant, and a T or M shows up only on the other. Click the padlock and look at the expiry date, which tells you whether automatic renewal is running; what else the certificate says and which error messages count is a guide of its own. And deliberately type your address with http://: you must land on the encrypted version without doing anything. A fault here takes priority, because almost nobody clicks past a certificate warning.

Step 2: Security headers in the browser

Every response from your server carries a few lines of instructions to the browser alongside the page itself. If they are missing the website still works, but the browser has less to fall back on when somebody tries to slip foreign content in. The overview comes from Mozilla's HTTP Observatory, running since 2016 and free today as part of the MDN documentation. It starts at 100 points, deducts for every missing or weak setting, and from 90 points upward awards bonus points in a second round, with the overall range running from 0 to 145. The grades: A+ from 100, A from 90, B from 70, C from 50, D from 30, and below 25 an F. A domain's scan history is publicly visible, though who ran the scan is not.

You can see the same thing directly in the browser: open the page, press F12, go to the Network tab, reload, click the top entry and read along under Response Headers. That is the fastest way to check whether a change has actually arrived. A poor grade does not mean your site is under attack, it means protective layers are missing that would help in an emergency. And a good grade does not mean your site is secure, it means these seven points are in order. The most dangerous finding from step 4 would not show up here at all.

Step 3: Outdated software and known vulnerabilities

The most common way into a small website is not a sophisticated attack, it is an extension whose gap has been publicly documented for months and unpatched for months. Germany's Federal Office for Information Security, the BSI, phrases exactly this as a core requirement for web applications: adequate vulnerability and patch management, and checking the components in use regularly for current security gaps. Its advice to small businesses is to keep an overview of the programs in use and install security updates as quickly as possible, or use the automatic update function. The same category sits high in the 2025 edition of the OWASP Top 10, as A03 Software Supply Chain Failures, the successor to what was still called "Vulnerable and Outdated Components" in 2021.

From the outside you check it like this:

1. Run Sucuri SiteCheck. The free service searches the delivered source for malicious code, checks blocklist status with bodies such as Google and PhishTank, and detects outdated systems and vulnerable extensions as far as they are visible from outside.
2. For WordPress, add WPScan. The service is run by Automattic, and its database holds over 83,700 documented gaps in core, plugins and themes. For small businesses the simplest route is the free Jetpack Protect, which matches that same database against the extensions you actually have installed. Database access through the interface is limited to 25 queries a day for non-commercial use.
3. Check your blocklist status at Google. The Google Transparency Report has a Safe Browsing site status lookup that tells you whether your address is classified as unsafe. That is the classification that warns visitors away from your site when things go wrong.
4. Keep your own list. Which extensions are installed, which has had no update in over a year, which do you still need. The most effective measure here is usually deletion, not updating.

Sucuri says something useful about the limits of this check itself: a remote scanner has limited access, results are not guaranteed, and it only sees what is visible at browser level, nothing server-side. Which is exactly why step 4 exists.

Step 4: Openly reachable admin areas

No online checker does this step for you. Open a private browser window so you are not logged in anywhere, and walk through your own website like a stranger:

1. Is an admin access point public that was not meant to be? Many customer and admin login pages must be reachable. Visibility alone is not a vulnerability. For an intended login, check strong unique passwords, MFA, rate limits, monitoring and, where practical, network restrictions. The more serious case is an access point you did not know was exposed.
2. Are directories displayed as a list? Call up a folder without a file name, your images folder for instance. You should see an error page, not a file listing.
3. Are backup copies sitting in the web directory? Archives and database dumps do not belong where anyone can download them, they belong in a separate backup.
4. Did configuration or version control data get shipped along? This happens above all when a site is published by file upload rather than through a build process. Such files regularly contain credentials.
5. Is an old test version still online? Search Google for site:your-domain.com and work through the whole result list. Forgotten secondary addresses and preview environments turn up there often, and they are maintained less carefully than the main site.
6. Does your robots.txt give away more than it should? It is a request to search engines, not a protection. Listing admin paths there publishes a table of contents.

Why this step carries so much weight shows in the ranking of the 2025 OWASP Top 10: Broken Access Control, meaning missing or incorrect access restrictions, sits at number 1, and Security Misconfiguration, meaning incorrectly configured systems, has moved up from fifth place to second. An automated header test covers neither.

The consumer-protection check answers a different question

Searching for a security check, many people in Germany land on the Fakeshop-Finder run by the Verbraucherzentrale, the consumer advice organisation. It is good and free, just for a different job: it answers the buyer's question of whether you can order from a shop, and for that it looks at the spelling of the address, the legal notice, payment methods, prices and trust seals. The result comes as a traffic light, green meaning the shop has not stood out negatively so far, amber meaning check further yourself, red meaning it may already have been flagged as a fake shop. For your own site that tells you whether it looks trustworthy to strangers. Whether something is technically exposed on your side, it does not answer.

What the results mean

After an hour you have three grades and a handwritten list. Now the point is not to confuse them.

That "how urgent" column is a first triage, not a CVSS assessment. For a confirmed vulnerability, CVSS 4.0 can document the technical severity with a vector and a score from 0 to 10. Operational priority then also depends on exposure, exploitability, data value, existing controls and business impact. A visible directory listing can be harmless or critical; one exploitable component may require immediate action.

What an online test fundamentally cannot see

This is the part providers of free checkers rarely stress, and the most important one. All four steps above look from the outside at a logged-out website. What stays systematically invisible:

• Everything server-side. Files, permissions, running processes, stored credentials. Sucuri writes as much itself; how you harden the server yourself is a guide of its own.
• Everything behind the login. Customer area, ordering system, admin interface. A test from outside never gets there.
• Whether user A can see user B's data. The category at number 1 on the OWASP list. Testable only by signing in with two accounts and trying by hand to cross the line.
• Errors in business logic. A discount code that can be redeemed any number of times. A form that creates a booking without payment. Technically correct, commercially a loss.
• Whether a reported finding even applies. A scanner recognises a pattern, not the context. False positives are the norm.
• Anything you did not name. The forgotten secondary address, the old shop, the mail configuration.
• The human being. Reused passwords, a convincing forged mail to accounting, an account that was never switched off when someone left.
• Whether your backups work. The BSI explicitly names creating and regularly testing backups as one of the first protective measures. Testing means restoring, not just creating.

And one less technical limit on top: a checker hands you a list, not an order. It does not know which subpage your enquiries come in through, and it does not know which of the seven messages you should touch first.

Where a staged test begins

This is exactly where Falk works in my business, my AI employee for security. He tests in four stages rather than one pass: from outside with no access at all, then as an unauthenticated visitor, and where I approve it, with access or a look at the source code. Within a stage he follows five phases: taking stock of the technology in use purely from publicly delivered files rather than assumptions, an attack surface model along the sign-in and session flow, manual tests for typical classes of weakness, a tool check of encryption and known patterns, and finally the assessment. Every finding comes with evidence, a rating against the CVSS standard and a concrete repair proposal with a priority, not just an anomaly on a list; how such an audit runs from authorisation to retest has its own post.

Three things about that are the real difference from a press-the-button checker. The approval: before a single request goes to the target system, a written approval for exactly that system is in place. The pace: the automated part runs deliberately throttled at four parallel requests capped at 20 per minute, with no load or stress testing and no trying out credentials, because a test must not disturb live operations. And the abort criteria: instability, unexpected data access or warnings about too many requests stop the test on the spot. The finished report then passes a separate review role before I get to see it.

That every engagement gets its own frame and its own approval for exactly the target system in question is the reason this work is serious. There is no off-the-shelf security test, because there is no off-the-shelf system to test: every application has different entry points, different data and different lines that must not be crossed. Setting that scope down in writing is the first piece of work on the engagement, not the paperwork before it. How Falk proceeds in detail, and where I deliberately hold him back, is on Finding Security Flaws: Meet Falk.

Frequently asked questions

What does a check with these tools cost?

Nothing. The Qualys SSL Labs SSL Server Test, Mozilla's HTTP Observatory, Sucuri SiteCheck, the Safe Browsing status in the Google Transparency Report and the Verbraucherzentrale Fakeshop-Finder are all free to use, as of September 2026. With WPScan, database access through the interface is limited to 25 queries a day for non-commercial use. What a commissioned test costs, by contrast, hangs on six drivers of effort, not on a price list.

May I test a client's or a competitor's website?

Not without written permission from the operator, in place before an active test and naming the system in question. Sections 202a and 202b of the German Criminal Code do not make every visit to a public page criminal: they require specially protected data and overcoming access protection, or a non-public data transmission. Active tests on someone else's system can still create criminal, contractual and operational risks. This is not legal advice, but written scope is a rule nobody negotiates over in my business.

Is an A+ grade proof that my website is secure?

No, and that is the most common mistake in reasoning. An A+ in the SSL test says the encryption is well set up for the hostname you tested. It says nothing about another address variant, an unexpectedly reachable admin interface, an extension unpatched for a year, or a flaw in access control. Grades each assess one slice, not the whole.

How often should I repeat this?

Two fixed occasions make sense: regularly, say quarterly, so an expired certificate or an outdated extension does not sit there for months. And always after a change to the website, so after a rebuild, a move or a larger update, because that is precisely when redirects and settings shift.

I wanted to check my website's privacy compliance, not the technology.

That is a different question, even if it sounds similar. Technically the issue is whether something is exposed. With privacy the issue is which data you collect, on what legal basis, and who you inform about it. For the use of AI tools I have written that up in Claude, privacy and GDPR.

How to carry on

Take an hour and work through the four steps in this order: SSL Server Test, HTTP Observatory, Sucuri SiteCheck, then the private browser window for the admin areas. Write every result down with a date in a table with three columns: finding, urgency, done on. That table is worth more than any single result, because on the next pass you can see what has moved and what has been open for a quarter. If you are setting your site up from scratch anyway, the check points belong in the plan from the start, and what you need for that is in Getting a Website Built. And if you want to go the step beyond, an AI employee who tests in stages and evidences every finding instead of just handing out a grade: the route there and the ready-made roles are in my community, Claude Practitioners.