What a security check covers, and what it does not

You send us the address of your website. We read what any browser and the public DNS records show, in five areas.

HTTPS and TLS, certificate included. Unencrypted data "can be intercepted by third parties, who can access and modify the data", warns MDN's TLS guide. HSTS tells browsers to use HTTPS only and stops visitors from clicking past certificate errors. For its max-age, MDN recommends at least six months, better two years. RFC 8996 deprecated TLS 1.0 and 1.1 in 2021. Under a CA/Browser Forum ballot passed in April 2025, the maximum certificate validity drops in steps from 398 to 47 days between March 2026 and March 2029. At that pace, renewal has to be automatic.

Security headers. Instructions your server sends with every page. A Content Security Policy controls which scripts a page may load, mainly as a defence against cross-site scripting, and its frame-ancestors directive protects against clickjacking. X-Content-Type-Options stops the browser from guessing file types. Referrer-Policy limits what other sites learn about where a visitor came from.

Software and plugin versions anyone can see. Old software "without up-to-date security patches can be susceptible to known version-specific exploits", says OWASP's testing guide. Hiding the version number does not fix that. Updating does.

Mail records. SPF lists the servers allowed to send mail for your domain. DMARC tells receivers what to do with mail that fails those checks. DKIM signs each message, but its key sits under a selector name you have to know or find, so we check DKIM where we can find it. Google has required SPF or DKIM from every sender since 1 February 2024, and DMARC from anyone sending more than 5,000 messages a day to Gmail.

Login pages anyone can reach. OWASP names /admin, wp-admin/ and /phpmyadmin/ among the usual addresses. We note which ones open for anyone. We make no login attempts.

We run nothing that could slow down or disturb your site, and we need no access, passwords or plugins from you. Within 3 working days you get the 5 findings that matter most, in writing, each with what it means for you and how to fix it. There is no sales call unless you ask for one.

1. Run the HTTP Observatory. Enter your domain at MDN's HTTP Observatory. It grades headers, cookies and the HTTPS redirect, and links each problem to a fix. Its FAQ notes that "the scan history for each domain is public", and that it does not test "for outdated software versions, SQL injection vulnerabilities, vulnerable content management system plugins". An A+ means your headers are in order. It says nothing about your certificate or your plugins.

2. Look up your mail records. This works on Windows, macOS and Linux:

nslookup -type=TXT example.com
nslookup -type=TXT _dmarc.example.com

In the first answer, look for exactly one record starting with v=spf1. RFC 7208 forbids a second one. It should end in -all, which marks mail from other servers as not authorised, or ~all, a "softfail": probably not authorised. The record may trigger at most 10 DNS lookups in total. Every include:, a, mx, ptr, exists and redirect= counts, and so do the ones inside the records you include. Past 10, the result is "permerror".

The second answer should start with v=DMARC1. p=none asks receivers for nothing. That is a fine place to start, and Google accepts it even from bulk senders. p=quarantine marks failing mail as suspicious. p=reject says failing mail is not a valid use of your domain, and receivers may refuse it during delivery. A guide that still recommends pct= follows the older RFC 7489. RFC 9989 from May 2026 replaces it, drops pct and adds a test mode, t=y.

For DKIM, send a mail to a second mailbox and open its full headers in your mail program. In Gmail that is "Show original" in the message menu, which also shows whether DKIM passed. The DKIM-Signature header names a selector (s=) and a domain (d=). With s=mail and d=example.com, run nslookup -type=TXT mail._domainkey.example.com. The answer should contain p= followed by a long key. An empty p= means the key was revoked.

3. Open your own admin page in a private window. Try https://www.example.com/wp-admin/, or wherever your backend lives. If the login form loads for anyone, follow the WordPress hardening handbook: turn on two-step authentication, and keep core and plugins current, because "older versions of WordPress are not maintained with security updates". If only your team needs the backend, put a server-side password in front of /wp-admin/, as the handbook suggests. Leave wp-admin/admin-ajax.php outside it, because the handbook warns that locking the whole folder can break features that use that file. The other route is to have your host let in only your office's IP address, which is what OWASP checks for.

The security check goes past what any visitor can see: web apps, servers and accounts. That needs your written go-ahead first. A signed scope names the systems we may review, and you confirm they belong to you. Without both we do not start. Data you share with us stays under a data-protection agreement.

We then look at what is exposed, what is outdated, and where access is wider than it needs to be. The Austrian Federal Economic Chamber (WKO) lists that last point among its basic measures: a company should have reduced access to files and programs to the extent required.

The security check page shows a sample report: HTTPS and TLS 1.3 OK, security headers 4 of 6, WordPress core up to date, 2 plugins outdated, 2FA on admin logins, backups restore-tested. It is a sample, not a client's result.

• Every domain you use, including the mail domain if it differs from the website.
• Your servers and where they run: the host, the hosting panel, who has the login.
• Web apps and plugins with their versions. The WKO lists an up-to-date register of devices and applications among its basic measures, and the OWASP Top 10:2025 says to "continuously inventory" component versions.
• Who has admin access to what, including former staff and agencies.
• The date and result of your last backup restore, not just of the last backup. Germany's BSI wants backups tested regularly.
• Earlier reports or findings. The UK NCSC advises sharing a current vulnerability assessment while the scope is set.
• The person who can sign the scope.

Findings come ranked by risk, in plain language, with the fixes we would do first. The NCSC expects "a severity rating for any issues found". OWASP wants a report to show the business owner "where material risks exist", and notes that high and medium risks can be prioritized for fixing.

A serious finding is not always hard to fix. MDN rates each of its security guides by impact and difficulty. A selection, in the order MDN recommends:

The first four rows do the most for the least work. A CSP takes longer, because every script and embed on the site has to be allowed in it. A missing Referrer-Policy matters less than it looks: without one, browsers already use strict-origin-when-cross-origin. SPF and DMARC are usually DNS edits. An outdated plugin with no update is a bigger decision: replace it, have it fixed, or carry the risk knowingly.

The NCSC is clear that "risk assessment and decisions on the application of fixes are your responsibility." You also decide who fixes what: you, your agency or us.

It is not a certificate. We issue no seals, accredited certificates or compliance sign-offs, and we do no ISO or NIS2 work.

It is not a guarantee. The NCSC compares a penetration test to a financial audit, an outside check that your own processes work. Such a test, it says, can only confirm that your systems were not vulnerable to known issues on the day of the test. OWASP adds that a penetration test "can only identify a small representative sample of all possible security risks". What holds for a penetration test holds for any review.

It does not replace patching. A check finds the outdated plugin, and only the update closes the gap. The BSI titles its eighth tip for companies "Patchen, patchen, patchen!" (patch, patch, patch). Our guide on PHP 8.2 reaching end of life shows what that means for a WordPress site.

Start with the free website check: send your website address and get the top 5 findings within 3 working days. For web apps, servers and accounts under a signed scope, book the security check. Hardening closes what a check finds: patch routines, TLS and headers, least-privilege access, two-factor logins, backups restored at least once, and monitoring. On maintenance, we test updates on a copy first, your site reports errors to our own error monitoring (GlitchTip), and you get a regular written report.

If something has already happened, see help after a breach. Do not delete anything, and do not restore an old backup while the hole is still open. If it is urgent, call +43 7235 233 85. We pick up Monday to Friday 8:00 to 15:00, Saturday and Sunday 9:00 to 12:00. Otherwise write through the contact form, and we usually reply within one business day.