Website security best practices: a practical checklist

TL;DR:

• Applying TLS/HTTPS, enabling two-factor authentication, and keeping software patched improves website security immediately. Regularly review security headers, backups, and third-party tools to reduce vulnerabilities and protect sensitive data efficiently.

The most impactful website security controls you can apply right now are: enforce TLS/HTTPS on every page, enable two-factor authentication (2FA) on all admin accounts, keep your CMS and plugins patched, apply least-privilege access, maintain tested backups, deploy a web application firewall (WAF), and set security headers including HSTS and a Content Security Policy (CSP). The OWASP Top Ten gives you the canonical list of web application risks to map against, and NCSC guidance recommends treating security as a design requirement from day one, not a patch applied afterwards. The UK government’s Cyber Security Breaches Survey found that only 47% of businesses had deployed two-factor authentication, which means more than half of UK sites are leaving one of the easiest wins on the table.

Five quick wins you can complete within an hour:

• Run your domain through SSL Labs’ SSL Test and fix any TLS misconfigurations or near-expiry warnings.
• Enable 2FA on every admin, CMS, and hosting account you own.
• Add the Strict-Transport-Security and X-Content-Type-Options: nosniff headers to your server config.
• Remove every unused plugin, theme, or extension from your CMS.
• Check your DNS records for a DMARC policy; adding one takes under an hour.

What the OWASP Top Ten means for your site

The OWASP Top Ten is the most widely used taxonomy for web application threats, and it maps directly onto the vulnerabilities attackers actually exploit on UK SME sites. Here is each category translated into a one-line risk and a one-line fix.

UK scan data shows the most frequent issues on small business sites are missing DMARC, absent security headers, outdated software, exposed config files, and unnecessary open ports. Those five map almost perfectly onto OWASP’s misconfiguration and vulnerable-components categories, so fixing them first gives you the biggest return.

Pro Tip: For the CSP header, start with Content-Security-Policy: default-src 'self' and then add exceptions only as your site genuinely needs them. A permissive wildcard CSP is barely better than no CSP at all.

A quick HSTS example for Apache:

Header always set Strict-Transport-Security "max-age=63072000; includeSubDomains; preload"

That single line tells browsers to refuse plain HTTP connections for two years, across all subdomains.

Your step-by-step website security checklist

Work through these in order. The fastest, highest-impact fixes come first.

1. Check your TLS certificate and configuration (15–30 minutes). Run your domain through SSL Labs. Fix any grade below A, and confirm your certificate auto-renewal is working. Certificate expiry within 30 days is an actionable alert; failing renewals are a surprisingly common cause of outages.

2. Enable 2FA on every admin account (10–20 minutes). The NCSC small business guide is clear: strong passwords combined with 2FA provide significant protection for minimal effort. Use an authenticator app rather than SMS where possible.

3. Patch your CMS, themes, and plugins (30 minutes to a few hours). Outdated plugins are the most common entry point for attackers on UK sites. Apply all pending updates, then remove anything you are not actively using.

4. Set your security headers (30–60 minutes). At minimum, add Strict-Transport-Security, X-Content-Type-Options: nosniff, X-Frame-Options: DENY, and a Content-Security-Policy. These four headers close off a wide range of injection and clickjacking vectors.

5. Validate all user input and encode all output (hours to days, depending on codebase). Every form field, URL parameter, and API endpoint is a potential injection point. Use server-side validation; never rely on client-side checks alone.

6. Deploy a WAF and rate limiting (1–2 hours for a cloud WAF). Cloudflare’s free tier gives you a basic WAF, DDoS mitigation, and rate limiting with minimal configuration. For higher-risk sites, a paid WAF with custom rulesets is worth the investment.

7. Configure DMARC, SPF, and DKIM for your domain (30–60 minutes). Missing DMARC is the single most common finding on UK SME sites. Start with p=none to monitor, then move to p=quarantine once you have confirmed your legitimate mail flows.

8. Test and schedule your backups (1–2 hours). A backup you have never restored is not a backup. Run a test restore to a staging environment, confirm the data is intact, and schedule automated daily backups with at least 30 days of retention.

9. Apply least-privilege access (1–2 hours). Every user and service account should have only the permissions it genuinely needs. Remove stale accounts, demote admin users who do not need that level, and use separate credentials for deployments.

10. Enable logging and set up monitoring alerts (2–4 hours). Log authentication events, admin actions, and error responses. Set an alert for repeated failed logins, unusual traffic spikes, and any 5xx error clusters.

11. Schedule a vulnerability scan and annual penetration test (ongoing). NCSC Web Check is a free scanning service for eligible organisations. Combine automated scans in your CI pipeline with a manual penetration test at least once a year or after any significant release.

Pro Tip: The most common deployment mistake is broken automated certificate renewal. Your Let’s Encrypt or hosting-provider cert may renew silently, or it may fail silently. Set a calendar reminder to check renewal logs monthly, and use an uptime monitor that alerts on SSL expiry.

How to prioritise fixes and build a proportionate security plan

NCSC’s secure-by-design guidance is explicit: security controls should be selected proportionate to the service’s risk profile and documented from the start of a project. That means your first job is a simple asset inventory: list what data you hold, who can access it, and what the impact would be if it were lost or exposed.

From there, score each risk by likelihood multiplied by impact. A public brochure site with no user accounts sits at a very different risk level from an e-commerce platform processing card data. Your controls should reflect that difference, not copy a generic enterprise checklist.

Sample prioritisation timeline:

• First 24 hours: TLS check, 2FA on admin accounts, security headers, DMARC record. All of these are free or near-free and take under an hour each.
• First 7 days: Full plugin audit and patching, WAF deployment, backup test, logging enabled.
• First 90 days: Input validation review, CSP rollout, penetration test scheduled, access control audit, staff awareness training.

The NCSC architecture guidance recommends layered defences and avoiding unnecessary features. That principle is practical: every service, port, or plugin you disable is an attack surface you no longer need to defend.

UK-relevant tools and services for the checklist

Choosing the right tool for each task matters more than using the most expensive one. Here is a practical breakdown by category.

A few UK-specific points worth noting. Data residency matters if you process personal data under UK GDPR: confirm that your backup and logging providers store data in the UK or EEA, or that you have a valid transfer mechanism in place. For WordPress sites, the security plugins available for Elementor and other page builders can add an extra layer of protection at the plugin level.

If you are using a hosted builder, check Webflow security plugin options for platform-specific hardening.

Key considerations when choosing between free and paid tools:

• Free tools are entirely adequate for most small sites, provided you actually use them consistently.
• Paid tools earn their cost when they include automated alerting, restore testing, or compliance reporting you would otherwise have to do manually.
• A managed service from an agency removes the burden of remembering to run checks at all.

Ongoing maintenance and how MB Web secures client websites

Security is not a one-time project. A practical maintenance schedule looks like this: weekly patch checks for CMS and plugins, monthly vulnerability scans, quarterly review of access controls and user accounts, and an annual architecture review or penetration test. Daily monitoring for critical alerts, such as failed logins, certificate issues, and unusual traffic, should run continuously.

When you are evaluating an agency to handle this, ask these questions directly:

• Can you show evidence of a secure-by-design approach in your development process?
• What is your backup and restore SLA, and how often do you test restores?
• How do you handle logging access and retention for client sites?
• What is your break-glass procedure if an admin account is locked out or compromised?
• How are client credentials stored and shared within your team?

MB Web builds security into every website project from the design phase, not as an afterthought. Our managed hosting and maintenance packages include routine patching, monitoring, and backup management, so clients are not left to remember these tasks themselves. We also carry out technical website audits that surface security gaps alongside performance and SEO issues, giving you a single, prioritised action list.

Pro Tip: Never use the same credentials for staging and production environments. Staging credentials left in a production config file are one of the most avoidable and most common security failures we see on client sites.

Detect, respond, and recover: your incident-response checklist

When something goes wrong, speed and order matter. Here is a compact playbook.

Detection and triage (first 30 minutes):

• Identify the affected systems and confirm the scope of the incident.
• Preserve logs immediately; do not restart servers or clear caches before collecting evidence.
• Rotate any compromised credentials, starting with admin and database accounts.
• Notify your hosting provider and activate any break-glass recovery procedures.

Containment and recovery (hours 1–24):

• Take the affected site offline or into maintenance mode if active exploitation is confirmed.
• Restore from the most recent clean backup, then test the restore before going live.
• Patch the exploited vector before bringing the site back up.
• Scan the restored site with OWASP ZAP or a similar tool before re-publishing.

UK-specific notes. Under UK GDPR, a personal data breach that is likely to result in a risk to individuals must be reported to the Information Commissioner’s Office (ICO) within 72 hours of becoming aware of it. Not every security incident triggers this obligation, but if user data has been accessed or exfiltrated, you need to assess quickly. Keep a written record of your decision-making process regardless of whether you report.

For domain takeover attempts, contact your registrar’s security team directly and use GDS guidance on registrar access controls to lock down DNS management. A DNS TTL of 300 seconds on critical records means you can respond to a hijack within minutes rather than waiting for a 24-hour TTL to expire.

Pro Tip: Keep a printed or offline copy of your break-glass procedure, your registrar login details, and your hosting provider’s emergency contact number. If your site is down and your password manager is hosted on the same server, you will be glad you did.

Input sanitisation and output encoding beyond the basics

The OWASP Top Ten covers injection and XSS at a high level, but the implementation details are where most sites fall short. Every piece of data entering your application, whether from a form field, a URL parameter, a REST API call, or an uploaded file, should be treated as untrusted by default.

Server-side validation is non-negotiable. Client-side checks improve user experience but can be bypassed in seconds. Validate for both syntactic correctness (is this a valid email format?) and semantic correctness (does this user ID actually exist and belong to this session?). For XML and JSON inputs, validate against a schema before processing.

Output encoding is the complement to input validation. Variables passed to the browser must go through an encoding function appropriate to their context: HTML encoding for content inserted into the DOM, JavaScript encoding for values inside script blocks, and URL encoding for values in query strings. Browsers parse HTML, JavaScript, and CSS differently, and using the wrong encoding method for the context can introduce the very weaknesses you are trying to prevent.

For sites using large language models (LLMs) or AI-generated content, treat all LLM outputs as untrusted input. Validate and sanitise before passing to other system components or displaying to users, and enforce strict access controls on the data and APIs the model can reach.

Security considerations for third-party integrations and plugins

Third-party plugins and integrations are the most common attack vector on WordPress and other CMS platforms. Every plugin you install is a dependency you are trusting to be maintained, patched, and free of malicious code. That trust is not always warranted.

Before installing any plugin or integration, check its update history, active installation count, and whether the developer responds to reported vulnerabilities. Prefer plugins with a track record of prompt security patches. After installation, monitor for updates and remove anything that has not been updated in over a year.

For third-party scripts loaded from external CDNs, consider hosting them locally where possible. The DWP security standard for web content recommends that JavaScript libraries, stylesheets, and web fonts be hosted by the application rather than retrieved from external providers. This removes a dependency on the security of the external host and prevents supply-chain attacks via compromised CDN resources.

Use a Software Bill of Materials (SBOM) and dependency vulnerability scanning tools to track what is in your stack. Dependabot on GitHub and npm audit for Node projects will flag known vulnerabilities automatically. Tie these scans to your release pipeline so you cannot ship a known vulnerable dependency.

Secure development lifecycle and code review practices

Security built into the development process costs far less to fix than security bolted on afterwards. The NCSC building and operating guidance recommends embedding security testing throughout the development lifecycle, using static analysis (SAST), dynamic analysis (DAST), and manual penetration tests at appropriate stages.

In practice, this means: running a linter with security rules on every commit, using pre-commit hooks to catch hardcoded secrets and insecure patterns before they reach the repository, and including dependency scanning in your CI pipeline. Code reviews should include a security checklist, not just a functionality review. A second pair of eyes on authentication logic, access control decisions, and any code that touches user data catches a significant proportion of vulnerabilities before they reach production.

Threat modelling at the design stage is worth the hour it takes. For each new feature, ask: what data does this touch, who can call it, and what happens if an attacker sends unexpected input? That conversation, documented and shared with the team, is the foundation of secure web development.

Security awareness training for developers and site maintainers

Technical controls only go so far. Phishing remains the most common initial access vector for UK businesses, and a developer with admin credentials who clicks a convincing email can undo months of hardening in seconds.

Practical training does not need to be expensive. The NCSC’s free Cyber Aware resources and the 10 Steps to Cyber Security guidance are written for exactly this audience. For development teams, OWASP’s free training materials and the Web Security Academy from PortSwigger cover the technical side in depth.

The most effective training is specific and regular, not a once-a-year compliance tick. Short monthly briefings on recent attack patterns, a shared Slack channel for security news, and a clear process for reporting suspected phishing all build the habit of security awareness without becoming burdensome. Pair this with a policy that makes it safe to report mistakes: a developer who accidentally commits a secret to a public repository needs to tell someone immediately, not hide it out of embarrassment.

Key takeaways

Applying TLS, 2FA, timely patching, a WAF, tested backups, and security headers together gives you the strongest practical defence against the threats most likely to affect a UK website.

Why secure-by-design matters more than a one-off fix

Most of the security incidents we see at MB Web share a common thread: security was treated as something to add later, once the site was live. A plugin installed in a hurry, an admin account never cleaned up after a staff change, a certificate renewal that silently failed three months ago. None of these are exotic attacks. They are the ordinary accumulation of small oversights.

The honest truth is that a checklist, however thorough, only gets you so far if no one is responsible for running through it regularly. The sites that stay secure are the ones where security is a habit, not a project. That means scheduled patch windows, tested backups, and someone who actually reads the monitoring alerts. It also means building security into the design of new features, not retrofitting it after a breach.

We are not saying this to sell you something. We are saying it because we have seen what happens when it is skipped, and it is always more expensive to fix after the fact than to maintain properly from the start. If you take nothing else from this guide, take this: pick the five quick wins from the opening section, do them today, and then schedule a proper review for next month. That rhythm, kept up, is what actually protects a site.

MB Web’s managed security and maintenance service

Securing a website properly takes time, knowledge, and consistency. If you would rather hand that responsibility to a team that does it every day, MB Web’s managed maintenance service covers exactly what this guide describes: routine patching, daily monitoring, automated backups with tested restores, security header configuration, and incident support when things go wrong.

Engagements typically start with a technical audit that surfaces your current vulnerabilities and prioritises them by risk. From there, we handle remediation and move into an ongoing maintenance agreement. There are no long-term contracts you cannot exit, and no hidden costs for the basics. Whether you need a full website development project built securely from scratch, or a maintenance wrapper around an existing site, we can help. Get in touch with the MB Web team to talk through what your site actually needs.

Useful sources and further reading

Save these links for your next audit or developer handover.

• NCSC Cyber Security Breaches Survey 2025/2026 — UK-specific data on breach prevalence, control adoption, and incident response across businesses and charities.
• NCSC Building and Operating a Secure Online Service — Practical guidance on secure development, testing, and monitoring for UK services.
• NCSC 10 Steps: Architecture and Configuration — Layered defence principles and secure configuration guidance.
• NCSC Secure by Design: Agreeing a Security Controls Set — How to select proportionate controls from project start.
• GDS Security Overview for Websites — Covers named accounts, MFA, DNS TTL recommendations, and registrar security.
• NCSC Web Check — Free automated scanning for eligible UK organisations; a practical starting point for routine checks.
• SSL Labs SSL Test — Run this against your domain to get an instant TLS configuration grade and certificate health report.
• OWASP Top Ten — The canonical taxonomy of web application risks; use it to map your controls and prioritise fixes.
• ICO — Reporting a Personal Data Breach — The ICO’s guidance on when and how to notify under UK GDPR, including the 72-hour window.

FAQ

How quickly can I improve my website’s security?

The five highest-impact controls, including TLS checks, 2FA, security headers, DMARC, and removing unused plugins, can all be completed within a few hours. Scan data shows DMARC and header fixes typically take under an hour each.

What is the OWASP Top Ten and why does it matter?

The OWASP Top Ten is the industry-standard list of the most critical web application security risks, covering threats such as injection, broken authentication, and security misconfiguration. It is the right starting point for prioritising which vulnerabilities to fix first on any site.

Do I need to report a website breach to the ICO?

If the breach involves personal data and is likely to result in a risk to individuals, you must notify the ICO within 72 hours of becoming aware of it under UK GDPR. Keep a written record of your assessment even if you decide not to report.

What does a WAF actually do for my site?

A web application firewall, such as Cloudflare’s free tier, filters malicious traffic before it reaches your server, blocking common attack patterns including SQL injection, XSS, and DDoS attempts. It is one of the fastest ways to add a meaningful layer of protection with minimal configuration.

Can MB Web handle security maintenance for an existing site?

Yes. MB Web’s managed maintenance service covers patching, monitoring, backups, and security configuration for existing sites, typically starting with a technical audit to identify and prioritise current vulnerabilities.

Recommended

• The role of security in websites: a guide for UK businesses
• Essential Website Maintenance Steps for Better SEO
• Website maintenance is CRUCIAL to Security on websites
• Website accessibility checklist guide for UK businesses