Guide

Website security check: test your own site step by step

By Lucas Weber, CyberSec42 · Updated 28 Oct 2026

A website security check is something a small business owner can largely do alone, with a browser and a handful of free tools: encryption and certificate, security headers, outdated software, exposed admin logins, malware and blacklist status, publicly downloadable files, forms, and the sender settings for your email. This guide shows, for each point, how to test it, what the result means and what to do if something turns up. What no automated scan will find are flaws in your site's logic and access rights. Those take a human tester.

Before you start

Only test your own website, or a site you have permission to test. Every tool in this guide requests your pages the way a visitor would and reads what they show publicly. For your own site, that is unproblematic.

Keep a simple log: check, result, date, open question. Anything you cannot answer yourself becomes a question for your host, your agency or your website builder. How to secure the basics, meaning accounts, two-factor login, backups and contracts, is covered in our small business website security checklist. This guide is about measuring: what does a stranger see when they examine your site from the outside?

1. Check HTTPS and the certificate

The certificate is your site's digital ID. It makes sure that what visitors type in, such as their name, email address or password, travels encrypted. A padlock in the browser is the first step. A closer test shows how well the encryption is actually configured.

How to check

• Open the free Qualys SSL Labs SSL Server Test and enter your domain. Tick “Do not show the results on the boards” first if you don't want your result to appear in the service's public lists.
• Also type your address once with http://. You should be redirected to the https:// version automatically.

How to read the result

Look for two details in the report. First, the certificate's expiry date and whether it renews automatically. Second, the protocols: Germany's Federal Office for Information Security (BSI) recommends in its technical guideline TR-02102-2 (version 2026-01) that TLS 1.3 be preferred, that TLS 1.2 be used only until the end of 2031, and that TLS 1.0 and 1.1 not be used at all. The Internet Engineering Task Force formally deprecated those two old versions in RFC 8996. If the report still lists them as “Yes”, that is a concrete question for your host.

On hosted builders such as Wix, Squarespace or Shopify, the provider handles encryption. A grade below A is no cause for concern there, because you cannot change it anyway.

2. Measure your security headers

Security headers are short instructions your site sends to the browser with every page, such as “only load this page over an encrypted connection” or “don't let other sites embed me”. They protect visitors against several common attacks, for example injected scripts or pages that invisibly overlay yours.

How to check

Enter your domain in Mozilla's free HTTP Observatory. It grades from A+ to F, starting from a baseline of 100 points, and shows what is missing for each test. According to Mozilla, a site can be rescanned at most once a minute.

An example from our own site: on 28 Oct 2026 the Observatory gave www.cybersec42.com an A+ with 110 points, 12 of 12 tests passed. A second measurement, fetching the page directly, confirms the headers behind that grade:

strict-transport-security: max-age=63072000; includeSubDomains; preload
content-security-policy: default-src 'self'; script-src 'self' 'sha256-…' …
x-content-type-options: nosniff
x-frame-options: DENY
referrer-policy: strict-origin-when-cross-origin
permissions-policy: geolocation=(), microphone=(), camera=(), …

How to read the result

Missing headers are a task for your web provider, not an emergency. What each header does and how to set it up on Apache, nginx, Netlify or Vercel is covered in our guide to Content Security Policy and security headers. Keep the tool's limits in mind: Mozilla's own FAQ states that even an A+ does not mean a site is secure. Outdated software, vulnerable plugins, SQL injection and password handling are not tested.

3. Find outdated CMS and plugin versions

A content management system (CMS) is the software you use to edit your site, such as WordPress, Joomla or Drupal. Plugins and themes extend it. Many known vulnerabilities in this kind of software were fixed long ago in an update, and automated attack tools look specifically for sites that never installed it.

How to check on WordPress

• In the admin area, open Tools → Site Health. Under “Status”, WordPress lists critical issues such as pending plugin updates, an outdated PHP version or error output switched on. Under “Info” it shows the versions of WordPress, your theme and every plugin (WordPress documentation).
• Check Dashboard → Updates for pending updates and Plugins for deactivated plugins lying around. Delete what you don't use rather than just deactivating it.
• For each plugin, look at its page in the WordPress plugin directory to see when it was last updated. A plugin that has not been maintained for years no longer gets security fixes either.

On other platforms

On hosted builders, the provider updates the platform itself. Your part is the apps and third-party extensions you have installed. If an agency looks after your site, ask for a list of every component with its version number and the date of its last update. If nobody can produce that list, you have already found your most important result. How to keep WordPress up to date for good is covered in our WordPress security guide.

4. Exposed admin logins

Your admin login page is the door with the biggest key ring. On WordPress it sits at /wp-admin/ by default, on Joomla at /administrator/. The testing guide published by OWASP, a non-profit for application security, lists such paths as typical targets because admin interfaces are often not adequately protected against unauthorised access (OWASP WSTG).

How to check

• Open the login page in a private browser window, ideally once over mobile data instead of your office Wi-Fi. If it is reachable from anywhere, that is normal for many sites. The login itself then has to be well protected.
• Is two-factor login switched on for every account with admin rights?
• Are there other admin interfaces, such as a database tool like phpMyAdmin, under your domain? That does not belong on the open internet. Ask your host where it can be reached.
• Ask your provider whether repeated failed logins are slowed down or blocked. Don't test this yourself with lots of attempts, or you may lock yourself out.

A good result: only people you know have admin rights, all of them use a second factor, and database or server administration is not publicly reachable.

5. Check malware and blacklist status

If malware or a scam page is found on your site, Google puts it on a blocklist. Browsers then show visitors a warning before they open the page. You are often the last to notice, because your own browser loads the page from its cache.

How to check

• Google Safe Browsing site status: In Google's Transparency Report, enter your domain to see whether Google currently rates it as dangerous. According to Google's developer documentation, Safe Browsing detects phishing and deceptive sites as well as sites that distribute malware or unwanted software. What you want to see is a result with no unsafe content flagged.
• Google Search Console: The “Security issues” report flags hacked content, malware and unwanted software, and social engineering, meaning content designed to trick visitors into doing something risky (Search Console Help). You need your own Search Console access for this.
• Search for content you didn't publish: Search Google for site:yourdomain.com and page through the results. Pages in a foreign language, or ads for pharmaceuticals or gambling that you never created, are a warning sign.

How to read the result

A clean result only means Google has not flagged anything at the moment. Some malware shows itself only to certain visitors, for example only to smartphones or only to people arriving from a search engine. If your site is listed or you find content you didn't publish, treat it as a breach and follow our guide Website hacked? What to do first. It also explains how to request a review from Google once the site is clean.

6. Publicly exposed files: backups, .git, .env

One of the most damaging mistakes is also one of the simplest: a file sits in the server's public folder where it does not belong. Anyone who guesses the address can download it. The OWASP testing guide names three groups that should generally never be served publicly (OWASP WSTG):

• Backups and archives such as .zip, .tar.gz, .bak or .old. A full backup often contains the entire site including the database, which means customer data and password hashes too.
• Configuration files such as .env. They often hold credentials for the database, mail server or payment provider in plain text.
• The .git folder created by the version control tool Git. If it is reachable, the full source code and its history can often be rebuilt from it, including passwords that were once committed and later deleted.

WordPress's Site Health screen also warns when errors are written to a log file that may be publicly accessible.

How to check

In a private browser window, add these paths to your domain and look at what comes back:

https://yourdomain.com/.git/HEAD
https://yourdomain.com/.env
https://yourdomain.com/backup.zip
https://yourdomain.com/wp-content/debug.log

How to read the result

• Good: a “not found” or “access denied” error page. On www.cybersec42.com, for example, /.git/HEAD and /.env both return a 404 error.
• Careful: some servers simply show your homepage for unknown addresses. What matters is the content, not whether “something loads”.
• Act now: you see a line such as ref: refs/heads/main, credentials, or a download starts. Have the file removed and treat every password and key in it as known: they need to be replaced, not just the file deleted.

A clean result is worth particularly little here. You tested four obvious names, but a forgotten file might be called site-old-2023.zip. So also ask your provider whether there are backups, exports or copies in the web folder, and have them moved somewhere outside the public area.

7. Forms and spam

Your contact form is where strangers send data to your server. Spam is the visible problem. What matters more is what the form accepts and where the data goes.

• Fill it in yourself: send a test message. Does it arrive? Is it also stored on the website, and who can read it there?
• Uploads: does the form accept attachments? Then it should only take specific file types, such as PDF, and uploaded files must not be publicly downloadable.
• Copy to sender: if the form sends a copy to the address entered, it can be abused to send messages through your server to anyone. Check whether you really need that feature.
• Spam protection: is there protection against automated submissions? If your inbox fills up with form spam, it is missing or not working.

What you cannot see from the outside: whether the server validates the input again itself or relies on the check in the browser. That difference is a classic attack vector and one of the things only a manual test reveals.

8. Email senders: SPF, DKIM and DMARC in brief

These three entries in your domain's name system (DNS) define who may send email in your name. Without them, scammers find it easier to send messages that appear to come from your address, such as fake invoices to your customers.

How to check

• Send yourself an email from your business address to a Gmail inbox. Open it in a browser, click the three dots next to “Reply” and then “Show original” (Gmail Help). At the top you will see a summary listing SPF, DKIM and DMARC. Ideally each one says PASS.
• If any of the three is missing, ask your email or domain provider.

Under the standard RFC 7489, DMARC has three levels: p=none (monitor and collect reports only), p=quarantine (treat failing mail as suspicious, for example by sending it to spam) and p=reject (refuse it). The usual approach is to start with none, read the reports and only then tighten the policy. Since 1 February 2024, Google has required all senders to Gmail to set up at least SPF or DKIM, and senders of more than 5,000 messages a day to set up SPF, DKIM and DMARC (Google email sender guidelines). So the setup also pays off in deliverability.

Website vulnerability scanners: where the tools stop

The eight checks above show how your site is configured from the outside. Automated tools, paid online scanners included, compare what they see against known patterns. What they fundamentally cannot judge is whether your site does what it is supposed to do, and nothing more:

• Access rights: does a logged-in customer see only their own orders, appointments or invoices? Or is changing a number in the address bar enough to see someone else's? A scanner does not know your customers and cannot tell the difference.
• Logic flaws: can a voucher be redeemed twice, a price changed in the cart, a checkout step skipped, or someone else's password reset through the “forgot password” feature? Technically everything works; the rule itself is wrong.
• Custom features: calculators, configurators, connections to your inventory system or calendar. Code written just for you has no known vulnerability in any database, so a scanner has nothing to match.
• Everything behind the login: most online tools only see public pages. Customer areas, admin areas and APIs go untested.

So the rule of thumb is this: for a purely informational site with a contact form, the eight checks are enough if you repeat them regularly. As soon as your site has a shop, customer accounts, a booking system or custom features, a manual test is worth it, with a person working through the site using several test accounts the way an attacker would. What that involves is explained in Penetration testing: process, duration and what it costs. If you want a broad overview first, our article on vulnerability assessments explains the difference.

Your website security check as a checklist

Repeat the list once a quarter and after every major change to the site, such as a new plugin or a change of provider. For systems that process personal data, the EU General Data Protection Regulation already requires a process for regularly testing the effectiveness of security measures (Art. 32(1)(d) GDPR). What that means for your business specifically is a legal question. This article is not legal advice.

Frequently asked questions

Further reading

• Small business website security: a checklist you can run yourself
• Content Security Policy and security headers: a practical setup guide
• WordPress security: the practical guide for businesses
• Website hacked? What to do first
• Shopify store security: what merchants have to do themselves
• Service: penetration testing with verified findings

Sources

• BSI: Technical Guideline TR-02102-2, Use of Transport Layer Security (version 2026-01)
• IETF RFC 8996: Deprecating TLS 1.0 and TLS 1.1
• IETF RFC 7489: Domain-based Message Authentication, Reporting, and Conformance (DMARC)
• EUR-Lex: Regulation (EU) 2016/679 (General Data Protection Regulation), Art. 32
• OWASP Web Security Testing Guide: Review Old Backup and Unreferenced Files for Sensitive Information
• OWASP Web Security Testing Guide: Enumerate Infrastructure and Application Admin Interfaces
• MDN HTTP Observatory: Frequently asked questions
• MDN HTTP Observatory: Tests and scoring
• Qualys SSL Labs: SSL Server Test
• Qualys SSL Labs: SSL Server Rating Guide
• Google Transparency Report: Safe Browsing site status
• Google for Developers: Safe Browsing
• Search Console Help: Security issues report
• Google: Email sender guidelines
• WordPress documentation: Site Health screen