A security baseline for business websites

Most attacks on business websites are not targeted. Automated tools scan the internet for known weaknesses, such as outdated plugins, reused passwords and exposed admin pages, and exploit whatever they find. A small set of well-maintained controls removes most of these opportunities.

This baseline is written for business websites built on common platforms, including WordPress, Shopify and custom frameworks. Some items apply only to self-hosted sites; hosted platforms handle parts of them for you.

01HTTPS everywhere, enforced with HSTS

• Serve every page over HTTPS with a valid certificate, and set certificates to renew automatically.
• Redirect all HTTP requests to HTTPS with a permanent redirect.
• Disable outdated protocol versions. TLS 1.2 and TLS 1.3 should be the only versions accepted.
• Add the Strict-Transport-Security header so browsers always use HTTPS for your domain.

Start HSTS with a short max-age and increase it once you are sure every subdomain supports HTTPS. Only add the includeSubDomains and preload options after checking every subdomain, because they are difficult to reverse.

02Security headers

HTTP response headers tell browsers how to handle your pages. They are inexpensive to add and limit the damage from several common attacks.

• Content-Security-Policy: lists the sources allowed to load scripts, styles, images and frames. It is the most effective defence against injected scripts, and it needs testing because a strict policy can block legitimate tools.
• X-Content-Type-Options: nosniff, which stops browsers guessing file types.
• Referrer-Policy, which limits how much of your URLs is shared with other sites.
• Permissions-Policy, which disables browser features your site does not use, such as camera or microphone access.
• frame-ancestors in the Content-Security-Policy, or X-Frame-Options, which prevents your pages being embedded by other sites.

Free scanners, such as Mozilla Observatory, report which headers are present and how they are configured.

03Updates

Known vulnerabilities in outdated software are the most common way into websites. Keep the platform, plugins, themes, server software and dependencies up to date. Apply security updates promptly, and test larger updates on a staging copy first. Remove plugins, themes and integrations that are no longer used, because inactive code can still be exploited.

04Multi-factor authentication and least privilege

• Turn on multi-factor authentication for every account that can change the website: the CMS, hosting, domain registrar, DNS provider, code repository and any connected services.
• Give each person their own account. Shared logins make it impossible to see who changed what or to remove one person's access.
• Grant the lowest role that allows each person to do their work. Content editors rarely need administrator rights.
• Remove accounts promptly when people or suppliers stop working with you, and review the list of accounts regularly.
• Store credentials in a password manager rather than in documents or email.

05Backups, with restore tests

A backup only has value if it can be restored. Back up both files and databases automatically, keep copies in a location separate from the hosting account, and keep enough history to go back to a point before a problem started. The 3-2-1 approach is a useful guide: three copies of the data, on two different types of storage, with one copy kept off-site.

06Monitoring

• Uptime monitoring with alerts to more than one person.
• Expiry reminders for the TLS certificate and the domain name.
• Alerts for new administrator accounts, failed login spikes and changes to core files.
• Server and application logs kept for a defined period, so incidents can be investigated.
• Regular vulnerability scans of the site and its plugins.

07WordPress specifics

WordPress is widely used, which makes it a common target. Most compromises come from plugins and weak logins rather than WordPress core.

• Install plugins only from reputable sources, and prefer plugins that are actively maintained.
• Enable automatic updates for minor core releases and for trusted plugins.
• Disable the built-in file editor by setting DISALLOW_FILE_EDIT in wp-config.php.
• Limit login attempts and protect the login page, for example with a web application firewall.
• Disable XML-RPC if no service you use depends on it.
• Avoid the username admin and do not display usernames publicly.
• Set correct file permissions, so the web server cannot modify files it does not need to.

08Incident contacts

When something goes wrong, time is lost finding out who to call. Prepare a contact list before you need it, and keep a copy outside the systems it covers.

• Hosting provider support and your account details.
• The developer or agency responsible for the website.
• Domain registrar and DNS provider.
• Payment provider, if the site takes payments.
• The person responsible for data protection, and any legal or insurance contacts.
• Internal decision makers who can approve taking the site offline.

Alongside the list, write down the first steps: who decides to take the site offline, how evidence such as logs is preserved, and how customers will be informed if their data is affected.

09Review the baseline regularly

Security settings drift as sites change, new plugins are added and people join or leave. Review this baseline at least once a year and after any major change to the website or its hosting.