Security configuration checks

Website security problems can be simple: settings left at their defaults, a backup file in a public folder, a staging copy that search engines can find, or a plugin nobody has updated. The OWASP Top 10, a ranked list of web application security risks published by the OWASP Foundation, puts security misconfiguration in second place in its 2025 edition. Our security configuration checks look for that class of problem from the outside, the way anyone probing your site would see it.

What we check

• HTTPS everywhere. Every page and asset loads over HTTPS, plain HTTP redirects to HTTPS in a single step, and there is no mixed content where a secure page pulls in an insecure file.
• Certificates. The certificate is valid for every hostname you use, including the version with and without www, and renewal is automatic.
• Response headers. Whether headers such as Strict-Transport-Security, X-Content-Type-Options, a framing policy, a referrer policy and a Content-Security-Policy are present and sensible for your site. We also note headers that reveal more than they need to, such as server and software version numbers.
• Exposed files and folders. Common locations for backups, configuration files, version control folders, database dumps, log files and installer scripts. If any of them can be downloaded, it goes straight to the top of the report.
• Directory listing. Whether folders without an index page show their contents.
• Admin and login exposure. Whether the login page is reachable at a predictable address, whether it reveals which usernames exist, and whether there is any visible rate limiting.
• Software freshness. Visible version numbers for the CMS, themes and plugins, compared against the vendor's current releases where that information is public.
• Forms and email. Whether contact forms can be abused to send messages to arbitrary addresses, and whether the site's domain has the basic email authentication records a mail provider expects.
• Staging and test copies. Whether a staging site is public, indexed, or shares a database with live.
• Cookies. Whether session cookies carry the Secure and HttpOnly attributes where they should.

How we work

These checks are passive or close to it. We read what the server sends, request well-known file locations, and look at the site as an ordinary visitor and an ordinary search engine would. We do not try to break in, guess passwords, run vulnerability scanners against your server at volume, or test anything that could disrupt the service. If we find something that looks like an active compromise, we stop testing and report it to you on its own, outside the normal report.

Before testing, we agree in writing which hostnames are in scope, so we never test infrastructure that is not yours. If your hosting is managed by a third party, check whether their terms require notice before any testing; we can supply a short description of what we will do.

How findings are ranked

Configuration findings vary widely in risk, so the report ranks them. At the top are findings that expose data or allow misuse straight away, such as a downloadable database backup or a form that can send email to any address. Next come weaknesses that make an attack easier, such as missing security headers or a login page that reveals valid usernames. At the bottom are tidy-ups, such as version numbers in headers. Each finding states which group it is in and why, so the order of work is clear.

What you receive

• A findings list ordered by risk, with the evidence for each item: the response header, the file address, or the screenshot.
• A plain explanation of why each finding matters and what a fix involves, without vendor-specific instructions you have not asked for.
• A clear statement of scope and of what was not tested.
• A recheck, if listed in the quote, once your developer or host has made changes.

What this service does not cover

This is not a penetration test, a code review, a vulnerability assessment of your server, or a compliance certification of any kind. A clean result means none of the configuration problems we looked for were visible from outside on the day of testing. It does not mean the site cannot be compromised. If your site handles payments, health information or anything else where the stakes are high, commission a penetration test from a specialist firm, and treat our checks as a pre-launch tidy-up rather than a substitute.

When to book security checks

• Before launch, after the site has moved to its final hosting and domain, because settings on staging are no guide to settings on live.
• After moving hosts or changing your CDN, when headers and redirects are easy to lose.
• Once or twice a year as routine, especially on CMS-based sites with several plugins.

Questions about security checks