13 ways to strengthen your website’s security

A website is part of a wider business system. Its registrar account, email inbox, hosting control panel, administrator devices and third-party integrations can all provide a route into the service. Protecting only the public pages leaves important gaps. A sensible security plan therefore starts with an inventory: who owns each account, who can change it, what information it holds and how it can be recovered.

Threats include stolen credentials, malicious uploads, vulnerable extensions, SQL injection, phishing and denial-of-service attacks. Their consequences differ, so there is no single switch that resolves them all. The following controls provide a practical starting point for a small UK organisation. Assign an owner to each task and check that it continues working after a redesign, staff change or migration.

1. Understand the hosting responsibility split

Ask which tasks the provider manages and which belong to your business or developer. Server maintenance, application updates, backups, malware investigation and recovery may be separate services. Record the supported software versions, access arrangements and escalation route. A plan’s storage allowance is not proof of its security controls. Keep your hosting contact and recovery information current so an incident does not begin with a lost-account problem.

2. Maintain the application and its dependencies

Keep the CMS, extensions, themes and supporting software within supported release ranges. Remove unused components instead of leaving them dormant on the server. Take a backup and test material updates on staging, especially where a shop depends on payment or subscription extensions. Record compatibility failures and resolve them rather than indefinitely postponing security fixes. Download packages from their official publisher or another source whose integrity you can verify.

3. Protect important accounts with stronger authentication

Use unique credentials for hosting, domain registration, email and the CMS. Enable passkeys where the service supports them, or use strong passwords with two-step verification. A password manager makes it practical to avoid reuse. Give each staff member an individual account and protect recovery codes separately. An administrator’s email account is particularly important because password-reset links often pass through it.

4. Serve the whole website over HTTPS

HTTPS protects data in transit between a browser and the server it reaches. Install a suitable certificate, maintain renewal and redirect normal HTTP visits to the intended HTTPS hostname. Check forms, embedded assets and any proxy-to-origin connection. HTTPS does not remove malicious code or make a dishonest website trustworthy; treat it as a necessary transport control alongside secure application design and account protection.

5. Configure a web application firewall carefully

A WAF can inspect web requests and apply rules against known attack patterns. Begin with an appropriate managed ruleset, review events and test business-critical forms. A rule that blocks a legitimate checkout or webhook needs a narrow investigation, not an unrestricted global exception. Keep a record of the reason, scope and review date for exceptions. Application fixes remain necessary even when a firewall reduces exposure to a vulnerability.

6. Keep recoverable, independent backups

Back up the database, uploaded files, application configuration and any material needed to rebuild the service. Match frequency to how much recent work the business could afford to lose. Keep at least one recovery copy outside the live account’s immediate failure path and restrict who can delete it. Test a restoration into an isolated environment. A successful backup notification alone does not prove that orders, media and configuration can be recovered together.

7. Reduce database exposure

Use application-specific database accounts with only the privileges they require. Avoid exposing database administration interfaces publicly without appropriate access controls. Developers should use parameterised queries rather than constructing SQL from untrusted input. Protect configuration files containing connection details and keep secrets out of repositories and logs. For a managed CMS, make database changes through its supported operations unless an administrator has a documented maintenance procedure.

8. Detect and investigate malicious changes

Monitor for unfamiliar administrator accounts, altered files, unexpected redirects and unusual outgoing messages. A scanner can be useful, but a clean result is not a guarantee that every compromise has been found. If an incident is suspected, preserve logs and evidence before replacing files. Determine how the attacker entered and remove persistence as well as visible malware. Restoring a backup without addressing the original weakness can lead to another compromise.

9. Apply least privilege to people and services

Editors rarely need permission to install executable code or manage other administrators. Give developers temporary access appropriate to the task and remove it when work ends. Review service accounts, API keys and integrations as well as human users. Separate production from staging where practical, and avoid copying real customer information into a loosely protected test site. Review access promptly when someone changes role or leaves the business.

10. Prepare for abusive traffic and service disruption

Rate limits, edge services and provider-level mitigation can help with unwanted traffic, but their scope varies. Understand which layers your service covers and how to contact support during an incident. Protect expensive endpoints such as search, login and report generation. Distinguish genuine demand from automated abuse before blocking broad regions or networks, which could also exclude legitimate UK customers and search crawlers.

11. Use logs and alerts that lead to action

Collect enough information to investigate authentication failures, administrative changes and application errors. Keep timestamps consistent and restrict access to logs, which may contain personal data or sensitive request details. Do not log passwords, complete payment-card details or secret tokens. Assign someone to review actionable alerts, and test the escalation path. A dashboard that nobody checks is not an effective incident process.

12. Control uploads and public files

Validate upload type, size and purpose on the server. Store customer files in locations with the appropriate visibility, and prevent uploaded content from becoming executable server code. Do not rely solely on a filename extension supplied by the browser. Keep private backups, configuration exports and deployment archives outside public web directories. Review old staging folders and temporary downloads after a project, retaining necessary recovery material privately.

13. Train the team and rehearse recovery

Teach staff how to verify a support request, recognise an unexpected sign-in prompt and report suspicious activity. Agree who can approve access changes and how identity will be checked if email is unavailable. Rehearse a small incident: for example, a compromised CMS account or an unavailable registrar. Make the response plan accessible independently of the website itself, so it remains available during an outage.

Build a routine, not a one-off checklist

Put recurring checks into normal operations: updates, backup restoration, account review and certificate renewal. After each change, test the tasks customers actually use. For a shop, that includes sign-in, basket updates, payment confirmation and transactional email. Record what was verified and the date, rather than labelling a site “fully secure”.

If personal information may have been affected, assess the incident under the applicable UK data-protection rules. Certain breaches must be reported to the ICO within 72 hours of awareness where feasible, and high-risk cases may also require prompt communication with affected people. Keep a record of the assessment and seek appropriate professional help when necessary. Prevention and recovery work best when technical owners and business decision-makers can act together.

Use a small, repeatable review record

Keep an inventory of the site, its main extensions, privileged accounts, backup locations and critical suppliers. For each control, record its owner and the last verification date. Use evidence such as a successful restore or a reviewed access list, with secret values excluded. When a supplier changes, check the related accounts, integrations and recovery routes together. This gives a new administrator a practical starting point and helps prevent important tasks depending on one person’s memory.