Pre-launch security configuration checks

Security misconfiguration sits at number two in the OWASP Top 10:2025, the ranked list of web application security risks published by the OWASP Foundation. Misconfiguration is the category of problems caused by settings rather than code: defaults left unchanged, features left switched on, files left in public folders. It is also the category a careful pre-launch check can do most about, because problems of this kind can be visible from outside and simple to fix once found.

This guide lists the checks we would run on any website before launch. Each one can be done with a browser, its developer tools, and some patience. None of them involves attacking the site.

1. HTTPS everywhere

• Load the site with http:// at the start of the address. It should redirect to https:// straight away.
• Try the version with www. and the version without. Both should end up at your preferred address over HTTPS, ideally in a single redirect.
• Open the browser's developer tools and look for mixed content warnings, where a secure page loads an image, script or font over plain HTTP.
• Check internal links and canonical tags use https:// addresses, not http:// ones that rely on redirects.

2. The certificate

• Click the padlock and check the certificate is valid and covers every hostname you use.
• Find out how renewal works. Certificates from automated authorities expire after a short period and must renew on their own. Someone should know what happens if renewal fails, and who gets the warning.

3. Response headers

Response headers are instructions the server sends with every page. A few of them improve security at little cost. In the developer tools, open the Network tab, select the page itself, and look at the response headers.

Headers interact with each other and with your site's features. A strict content security policy can break third-party widgets until it is tuned. Add headers on staging first, then test every page and flow.

4. Files and folders that should not be public

Try these in the browser. Each should return a "not found" or "forbidden" response, never a download or a listing.

• Version control folders, such as /.git/.
• Environment and configuration files, such as /.env or a CMS configuration backup.
• Database exports and site backups, which can have names like backup.zip, site.sql or the domain name with a date.
• Log files and debug output.
• Installer and setup scripts left over from installation.
• Folders without an index page: they should not list their contents.

If anything sensitive can be downloaded, treat it as a blocker. Remove it, then assume the contents may already have been seen, and change any passwords or keys inside.

5. The admin area

• Review every admin account. Remove people who have left, agencies who have finished, and test users.
• Make sure each person has their own login and the lowest level of access they need.
• Turn on two-factor authentication for admin accounts where the platform supports it.
• Check whether the login page reveals whether a username exists. "Unknown username" versus "wrong password" tells an attacker half the answer.
• Check whether repeated failed logins are slowed down or blocked.

6. Software freshness

• Update the CMS, theme and plugins to current versions before launch, then test.
• Remove plugins and themes that are installed but not used. Inactive code can still be a risk.
• Note where automatic updates are on or off, and why. On WordPress, for example, the documentation explains that since version 5.5 administrators can opt in to automatic updates plugin by plugin and theme by theme, and that by default WordPress runs auto-updates twice per day.

7. Staging and test copies

• Find out where the staging site lives and who can reach it. A public staging site can be indexed, and it may contain test accounts or older, unpatched software.
• Protect it with a password or restrict it by network, and make sure it carries a noindex rule.
• Check it does not share a database with the live site.

8. Forms and email

• Check that forms cannot be used to send email to addresses the visitor chooses. See our guide to testing contact forms.
• Check the domain has the email authentication records your mail provider recommends, so messages from the site are not treated as spam and the domain is harder to spoof.

9. Cookies

In the developer tools, look at the cookies the site sets. Session and login cookies should carry the Secure attribute, so they are only sent over HTTPS, and the HttpOnly attribute, so scripts on the page cannot read them.

Recording what you found

Write the results down, even when everything passes. A short record for each check, with the date, is enough:

The record shows what was checked and what the site looked like that day. When something changes later, such as a host move that drops a header, the record makes the difference obvious. It also gives anyone asking about the site's security posture a factual starting point rather than a recollection.

When to repeat the checks

Configuration drifts. Settings that were right at launch can change without anyone deciding to change them. Repeat the checks:

• after moving to a new host, server or CDN;
• after a major CMS version or a change of theme;
• after adding a plugin that handles logins, forms or payments;
• when a certificate is replaced or a domain is added;
• on a regular schedule, such as every six months, if none of the above has happened.

Each repeat takes less time than the first, because the record shows what to look for.

What these checks are not

They are a pre-launch tidy-up of visible configuration, not an assessment of how well the site resists a determined attacker. A clean result means none of these problems were visible from outside on the day. For sites that handle payments, health data or other sensitive information, commission a penetration test from a specialist, and keep these checks as the routine that runs before and after it.

A note on obligations

Article 32 of the GDPR requires appropriate technical and organisational measures to secure personal data. Among the measures it lists, to be used as appropriate, is "a process for regularly testing, assessing and evaluating the effectiveness" of those measures. Configuration checks can form part of that process. Whether your overall measures are appropriate is a judgement for your organisation and its advisers; a QA check does not settle it.

Sources

• OWASP Top 10:2025
• Plugins and themes auto-updates, WordPress documentation
• Regulation (EU) 2016/679 (GDPR), Article 32, EUR-Lex

Sources were read on 4 November 2026.