Website security hardening is the work of removing the weaknesses attackers actually use to compromise business websites, layer by layer, so that a site is no longer the easiest target on the street. It matters because most compromises of UK business websites are not sophisticated. They exploit known, published, patchable weaknesses: an outdated plugin, a content management system several versions behind, an administrator account with a reused password, a forgotten staging site, a third-party library nobody has updated since the site launched.
That is good news, because known weaknesses can be fixed. It is also uncomfortable news, because it means most compromised sites were not unlucky. They were running software with publicly documented flaws for weeks or months, often after a fix was available, and nobody was watching closely enough to notice when someone took advantage. Many businesses only find out when a customer reports a strange redirect, a search engine flags the site as harmful, or a payment provider raises a concern.
This guide starts with how UK business websites are actually compromised, then works through practical hardening layers: knowing what you run and patching it on a defined cadence, protecting administrative access, preventing cross-site scripting and SQL injection through input validation and output encoding, using a web application firewall as a compensating control rather than a cure, and setting up the monitoring that catches a compromise in hours rather than months. It is written for business owners, marketing leads and IT managers who are responsible for a site but may not write its code.
What website security hardening means
Hardening means reducing a system’s attack surface and strengthening what remains. For a website, that covers the software it runs on (the content management system, plugins, themes, frameworks and libraries), the server or hosting platform, the administrative accounts and interfaces, the code that handles user input, and the processes around all of these: who updates what, how often, and how anyone would know if something went wrong.
No single control makes a site secure. Hardening works in layers, on the assumption that any one layer may fail. A patched plugin prevents a known exploit; strong administrative authentication prevents a stolen password from being enough; careful input handling prevents a coding mistake from becoming a breach; a web application firewall blocks some attacks that slip through; monitoring catches what all of those miss. Each layer reduces the chance that an attacker succeeds, and the last reduces how long they get away with it.
Hardening is also continuous rather than a one-off project. A site hardened at launch and left alone becomes steadily less secure as new vulnerabilities are published in the software it uses. The most important hardening control for most business sites is not technical at all: it is a defined owner and a regular routine for keeping things up to date.
Before anything else, list exactly what your website runs: the platform and version, every plugin, theme, extension and major library, the hosting environment, every administrator account, and any other sites, staging environments or subdomains you own. Most businesses find something they had forgotten about. You cannot patch, monitor or remove what you do not know exists.
UK business website security — the numbers
The figures below are indicative, drawn from website security reviews and incident clean-ups we carry out for UK businesses. They are not a formal survey, but the pattern is consistent across sectors and site types.
The second and fourth figures describe conditions, not incidents: they are true of many sites that have never been compromised. That is the point. Each is a door left open, and attackers use automated tools to scan large numbers of sites for exactly these conditions. Closing them does not require sophisticated security; it requires knowing they exist and having someone responsible for closing them.
How UK business websites actually get compromised
Understanding the real routes in is the best guide to where hardening effort should go. The majority of compromises we see follow a small number of well-worn paths.
Outdated plugins, themes and extensions
Content management systems such as WordPress, Drupal and Joomla owe much of their flexibility to add-ons written by third parties. Each one is additional code running on your site, and each has its own vulnerabilities, published as they are discovered. WordPress plugin vulnerabilities are among the most common causes of business site compromises, not because WordPress is uniquely weak but because it is so widely used and its plugin ecosystem so large. When a vulnerability is published, automated scanning for sites running the affected version often begins within days. Sites that update promptly are rarely affected; sites that update occasionally are exposed for the whole gap.
Outdated platform cores
The same applies to the platform itself. Major platforms generally fix security issues promptly, but only sites running the fixed version benefit. Sites left several versions behind, sometimes because an update once broke something and nobody tried again, accumulate known weaknesses.
Weak or stolen administrative credentials
Administrator logins are a constant target. Reused passwords exposed in breaches elsewhere, shared agency logins, accounts belonging to people who left years ago and a lack of multi-factor authentication all make it easier for an attacker to simply log in, at which point most other defences are irrelevant.
Unpatched dependencies in custom sites
Custom-built sites and web applications avoid plugin sprawl but depend on frameworks and libraries, often dozens or hundreds of them, pulled in through package managers. These also receive security fixes, and sites built once and never updated gradually fall behind, sometimes on components the original developers barely knew they were using.
Coding flaws in input handling
Cross-site scripting and SQL injection remain common in custom code, bespoke plugins and older applications. They arise when input from users is trusted too readily, either inserted into database queries in an unsafe way or reflected back into pages without being encoded. These are well understood, well documented and preventable with established practices.
Forgotten assets
Old microsites, campaign landing pages, staging copies, test installations and subdomains that point at services no longer in use. They are rarely patched, rarely monitored and often share credentials or hosting with the main site.
Third-party scripts and hosting weaknesses
Analytics, chat, advertising and payment scripts loaded from other providers run with the same privileges as your own code in visitors’ browsers. Hosting control panels, file transfer accounts and database interfaces exposed to the internet with weak protection provide further routes. These are less common than the first four, but they are harder to spot.
Exposure by type of site
Different kinds of business website carry different risk profiles. The score grid compares three common types across the main exposure dimensions; a high badge means higher exposure on that dimension.
A self-hosted CMS site with many plugins is exposed mainly through its components and logins: the risk is concentrated in keeping everything updated and access tightly controlled. A custom web application shifts the risk towards the code itself and its dependencies, and usually holds more sensitive data, so secure coding practices and dependency management matter most. A hosted e-commerce platform takes much of the patching burden away, because the provider maintains the core, but administrator accounts, installed apps and any custom scripts remain your responsibility. Knowing which profile your site fits tells you where to start.
The root causes behind the compromises we see
The chart shows the contributing factors we find most often when cleaning up compromised UK business websites. Many incidents involve more than one factor, so the figures add up to more than 100%.
Two things stand out. First, the leading technical cause is not a clever attack but a component that should have been updated. Second, the absence of monitoring appears in more than half of incidents: not as the way in, but as the reason the attacker had weeks or months to use the site before anyone noticed. A compromise found in hours is usually a nuisance; one found after three months can mean stolen data, search ranking damage and a much larger clean-up.
For a broader introduction to the attack types themselves, our earlier guide to securing your business website against hackers covers each in overview. The rest of this guide focuses on the practical hardening layers and routines that address these root causes.
Layer one: patch management cadence
Because outdated components are the leading route in, a defined patching routine is the single most valuable hardening control for most business sites. “We update it when we remember” is not a routine. A cadence sets out what is updated, how often, by whom, and how urgent security fixes are handled between scheduled updates.
A sensible default cadence
- Critical security fixes: applied within a few days of release, and sooner where a vulnerability is known to be actively exploited. This requires someone to be watching for security announcements affecting the components you use.
- Routine updates to plugins, themes, extensions and libraries: applied on a regular schedule, typically weekly or fortnightly for CMS sites and at least monthly for custom applications.
- Platform core and framework updates: minor and security releases applied promptly; major version upgrades planned and tested as small projects.
- Server and hosting software: handled by the hosting provider on managed hosting, or by whoever manages the server otherwise, on a defined schedule.
Making updates safe
The main reason sites fall behind is fear that an update will break something. That fear is reasonable — updates do occasionally cause problems — and the answer is a safe process rather than avoidance. Take a backup before updating. Where the site matters commercially, apply updates to a staging copy first and check key pages and functions. Update in small batches rather than all at once, so any problem can be traced. Keep a short record of what was updated and when.
Removing what you do not need
Every plugin, theme or library removed is one less thing to patch. Deactivated plugins that remain installed can still be vulnerable on some platforms. Review the inventory periodically and remove anything unused, abandoned by its developer, or duplicating functionality available elsewhere. Components that have not been updated by their developer for a long time are a particular risk, because vulnerabilities found in them may never be fixed.
Watching for vulnerabilities
For CMS sites, security plugins and services can alert you when a component you use has a published vulnerability. For custom applications, dependency scanning tools built into many code hosting and build platforms flag vulnerable libraries automatically. Either way, the alerts are only useful if someone is responsible for acting on them. Our guide to patch management for SMEs covers the wider process across devices and servers.
Layer two: protecting administrative access
If an attacker can log in as an administrator, almost every other control can be bypassed. Protecting administrative access is therefore the second priority, and most of it costs nothing.
- Multi-factor authentication for every administrative account. Most platforms support it natively or through well-established extensions. It is the most effective single control against stolen and reused passwords.
- Individual accounts for everyone. No shared logins between staff or with agencies, so that access can be removed individually and actions traced.
- Least privilege. Content editors do not need full administrator rights. Give each person the lowest role that lets them do their job.
- Regular access review. Remove accounts for former staff, agencies and contractors promptly, and review the full list at least quarterly.
- Login protection. Limit repeated failed login attempts and alert on unusual login activity, such as logins from unexpected countries or at unusual times.
- Protect the other doors. Hosting control panels, file transfer accounts, database interfaces and domain registrar accounts deserve the same protection. A compromised registrar or hosting account can be worse than a compromised site.
Restricting access to administrative areas by network location, where the platform and working patterns allow, adds a further layer. It is not always practical for teams working from many locations, but where it is, it removes administrative login pages from the reach of most automated attacks.
Hosting and server-level hardening
The hosting environment sits underneath everything else. On fully managed platforms much of it is handled for you; on shared hosting, virtual servers and cloud instances, more of it is your responsibility or your developer’s. Either way, it is worth confirming that the basics are covered.
Supported runtime versions
The language runtime a site depends on — for many CMS sites, a particular version of PHP — has its own support lifecycle. Versions past end of support no longer receive security fixes. Hosting control panels often let the version be changed easily, but sites built for an older version may need updating first, which is a common reason they are left behind. Check the version in use and plan upgrades before support ends.
Separation between sites
Hosting several sites under a single account, particularly on shared hosting, means a compromise of one can spread to the others. Old microsites and test installations sitting alongside the main site are a frequent route for this. Where possible, keep each site in its own account or container, and remove anything that is no longer needed.
Secure file access and permissions
Use encrypted file transfer rather than older unencrypted methods, and give file access only to the people who need it. File and folder permissions should allow the web server to read what it needs and write only where it must, such as upload folders, so that a flaw cannot easily be used to alter the site’s own code. Upload folders should not allow uploaded files to be run as code.
Databases and services
Databases should normally accept connections only from the application, not from the internet at large. Database administration tools, if installed, should be protected or removed. Services that are not needed should be disabled, reducing what an attacker can reach.
Error messages and information exposure
Detailed error messages, version numbers in page headers and publicly readable configuration or backup files can all give attackers useful information. Production sites should show generic error pages to visitors while logging details privately, and backup files should never be stored in publicly reachable folders.
Backups that sit somewhere else
Backups held only on the same hosting account as the site can be lost or altered in the same incident. Keep copies elsewhere, retain them long enough to predate a compromise that may have gone unnoticed for weeks, and test restoring them.
The cost of hardening versus the cost of a compromise
The table compares indicative costs of the main hardening layers with what their absence typically costs when a business site is compromised. Figures are broad ranges for UK business sites and depend heavily on the site’s complexity, the data it holds and how central it is to revenue.
| Hardening layer | Indicative cost | Typical cost when missing and exploited | Who usually feels it |
|---|---|---|---|
| Managed patching and updates | £50 to £300 per month for a typical business site | Clean-up of £1,000 to £10,000 or more, plus downtime and lost enquiries | Marketing, sales, customers |
| Multi-factor authentication and access review | Usually free; an hour per quarter to review | Full site takeover, defacement or malicious content served to visitors | Brand, customers |
| Secure coding review of custom code | £1,500 to £10,000 depending on scope | Data exposure, regulatory reporting, customer notification | Customers, leadership, legal |
| Web application firewall | Free tiers to around £200 per month for business plans | Exposure to automated attacks during gaps in patching | Whole business |
| Monitoring and alerting | £10 to £150 per month | Compromises running undetected for months; search ranking and reputation damage | Marketing, customers |
The comparison is lopsided in the same direction for every layer. The ongoing costs are modest and predictable; the costs of compromise are unpredictable and often much larger once lost business, search visibility, staff time and, where personal data is involved, regulatory obligations are counted. Search engines may warn visitors away from a site flagged as compromised, which for a business that depends on online enquiries can be the most expensive consequence of all.
A 90-day hardening programme
The timeline sets out a realistic sequence for hardening an existing business website that has had little security attention. It deliberately starts with the highest-impact, lowest-effort controls.
By the end of the programme, the most common routes in — outdated components, weak access and forgotten assets — have been closed, monitoring is in place, and an ongoing routine has been agreed. Most of the value is delivered in the first month, which is worth remembering for businesses that cannot do everything at once.
Layer three: preventing XSS and SQL injection
Cross-site scripting and SQL injection are two of the longest-standing classes of web vulnerability, and both remain common in custom code, bespoke plugins and older applications. Both arise from the same root mistake: treating input from outside the application as trustworthy. Both are prevented by well-established secure coding practices that any competent web developer should follow as a matter of course. Business owners do not need to implement these themselves, but it helps to know what to ask for.
SQL injection: keep data and commands separate
SQL injection happens when user input is combined with a database query in a way that lets the input change the query’s meaning, potentially exposing or altering data. The primary prevention is parameterised queries, sometimes called prepared statements, in which the query structure and the user-supplied values are sent to the database separately so that input can only ever be treated as data. Most modern frameworks and database libraries support this by default, and using them consistently removes most of the risk. Additional layers include giving the application’s database account only the permissions it needs, so that even a flaw has limited reach.
Cross-site scripting: encode output for its context
Cross-site scripting happens when input supplied by one user is included in a page shown to others in a way that lets it run as script in their browsers, potentially stealing sessions or altering what they see. The primary prevention is output encoding: converting characters that have special meaning in a web page into a safe form before displaying any data that originated outside the application, with encoding appropriate to where the data appears. Modern templating systems usually do this automatically; the risk arises when developers bypass that protection or build pages by joining strings together.
Validate input as a supporting control
Input validation checks that data matches what is expected — a postcode looks like a postcode, a quantity is a positive number, a field is not unreasonably long — and rejects anything else. Validation should be done on the server, since anything done only in the browser can be bypassed. It is valuable and reduces many risks, but it supports rather than replaces parameterised queries and output encoding, because valid-looking input can still be harmful in the wrong context.
Add defence in depth
A content security policy instructs browsers which sources of script and other content to trust, which can limit the damage if a cross-site scripting flaw does exist. Our guide to website security headers covers this and other headers in detail. Marking session cookies so that scripts cannot read them, and so that they are only sent over secure connections, further limits what an attacker could gain.
What to ask your developers
Ask whether all database access uses parameterised queries or a framework that does so, whether output encoding is automatic in the templating system and where it is bypassed, how input is validated on the server, whether dependencies are scanned for known vulnerabilities, and whether code is reviewed by a second developer before release. Clear, confident answers to each are a good sign.
A firewall as the plan versus a firewall as one layer
Web application firewalls are often sold, and bought, as the answer to website security. They are valuable, but the way they are used makes a large difference. The comparison shows two approaches.
The firewall as the plan
WAF installed in place of other hardening
The firewall as one layer
WAF as a compensating control within layered hardening
The right way to think about a web application firewall is as a compensating control: something that reduces risk while other controls catch up, or blocks attacks that other layers might miss. It is particularly useful in the window between a vulnerability being published and a site being patched, and in blocking high volumes of automated scanning and login attempts. It is not a substitute for patching, access control or secure code.
Layer four: using a website firewall well
A web application firewall sits between visitors and your site, inspecting requests and blocking those that match patterns associated with attacks, such as attempts to exploit known vulnerabilities, automated login attempts and abusive traffic. For most business sites, it is now inexpensive and quick to add.
Where it sits
Website firewalls come in two broad forms. Cloud-based services sit in front of the site, usually alongside a content delivery network, and filter traffic before it reaches your hosting; they also absorb much of the load from automated attacks. Plugin or server-based firewalls run on the hosting itself and can see more of the application’s context, but use the site’s own resources and only act once traffic has arrived. Many businesses use a cloud-based service as the main layer, sometimes with a platform-specific security plugin alongside.
What it does well
Firewalls are effective at blocking automated scanning for known vulnerabilities, often with rules updated quickly when new vulnerabilities are published, which gives valuable cover while patches are applied. They limit brute-force login attempts, filter traffic from known abusive sources and absorb some volumetric attacks.
What it cannot do
A firewall cannot distinguish a legitimate login from one using a stolen password. It may not recognise attacks against flaws specific to your custom code. It cannot fix vulnerable software, only make it harder to reach. And it does nothing if attackers find a way around it, for example by reaching the hosting directly if the origin server is not restricted to accept traffic only from the firewall service.
Making it effective
Restrict the origin server so that it only accepts web traffic from the firewall service, otherwise attackers can bypass it. Start in a monitoring mode if the service supports it, check what would be blocked, then move to blocking once false positives are understood. Review the configuration periodically, especially after significant site changes. Make sure alerts go to someone who will act on them.
Website security posture — where most UK business sites sit
Combining the hardening layers in this guide gives an indication of overall security posture. The gauge reflects a typical UK business website, of any type, before any deliberate hardening work has been done.
A score in the high thirties usually reflects a site that has some protections — HTTPS, perhaps a security plugin, backups of some kind — but no routine. Updates happen irregularly, administrative accounts have accumulated, monitoring is limited to noticing when the site is down, and nobody is clearly responsible for security as distinct from content and design.
The 90-day programme above typically moves a site into the seventies, and most of that improvement comes from the first month: access controls, catching up on updates and removing forgotten assets. Reaching higher depends on the site: for custom applications, secure coding review and dependency management; for all sites, a routine that is actually followed month after month.
Hardening practices in place on UK business sites
The progress bars show how often each practice is in place across the UK business websites we review. Figures are indicative rather than a formal survey.
Website hardening practices in place
The practices most often in place are those that are set up once or provided by default, such as HTTPS and hosting backups. The least common are those that need ongoing attention or an owner: multi-factor authentication across every account, monitoring for changes rather than just downtime, and testing that backups can actually be restored. These gaps line up closely with the root causes in the earlier chart.
Layer five: monitoring that catches a compromise early
Every other layer can fail. Monitoring determines whether a failure is discovered in hours or in months, and that difference often matters more than the original weakness. Compromised business sites are commonly used quietly: to host spam pages that damage search rankings, to redirect some visitors to malicious sites, to harvest form submissions or to attack others. Attackers generally prefer not to be noticed, so “the site is still up” tells you very little.
Useful monitoring for a business site includes:
- Uptime and response monitoring. The baseline: alerts when the site is down or slow.
- Content and file change monitoring. Alerts when core files, templates or key pages change unexpectedly. This is one of the most reliable ways to spot a compromise early.
- Administrative activity alerts. Notifications for new administrator accounts, logins from unusual locations and changes to security settings.
- Search engine webmaster tools. Search engines notify site owners when they detect malware, spam content or security issues, often before anyone else notices. Make sure these notifications reach a monitored mailbox.
- Vulnerability alerts. Notifications when a component you use has a published vulnerability.
- Firewall and hosting logs. Reviewed periodically, with alerts for unusual patterns.
- External scanning. Periodic external scans that check what the site exposes and whether known issues are present. Our guide to vulnerability scanning explains how this works.
Monitoring only helps if alerts reach someone who will act. Decide who receives each alert, what they should do, and who covers when they are away. An alert sent to a former employee’s mailbox, or to a shared inbox nobody reads, provides no protection.
Who notices first
Across the compromised UK business sites we clean up, the proportion where the compromise was first noticed by someone outside the business, rather than by the business or its own monitoring, is high.
The figure is indicative rather than a formal survey. When an outsider is first to notice, the compromise has usually been running for some time, the damage is visible to customers, and the business is responding under pressure. When the business’s own monitoring catches it, the response can start before customers are affected, and the clean-up is typically smaller and faster.
Content and file change monitoring and administrative activity alerts do most of the work of shifting this balance. They are inexpensive, widely available and, once tuned, generate few false alarms.
Third-party scripts and the wider supply chain
A typical business website loads scripts from several other organisations: analytics, tag managers, chat widgets, advertising and remarketing tags, review widgets, video players, fonts and payment forms. Each runs in visitors’ browsers with much the same access as your own code. If one of those providers is compromised, or a tag is added carelessly, your visitors can be affected without any change to your own site.
Practical steps reduce this exposure. Keep an inventory of third-party scripts and remove any no longer needed; marketing tags in particular tend to accumulate. Control who can add scripts, especially through tag managers, which can let anyone with access add code to every page. Use a content security policy to restrict where scripts can load from. Where scripts are loaded from fixed versions, integrity checks can ensure the file has not been altered. For pages that handle payments or sensitive data, keep third-party scripts to a minimum.
The same thinking applies to development dependencies. Custom sites built from packages pulled in through package managers inherit the security of those packages and their maintainers. Dependency scanning, a lock on exact versions and a review before adding new dependencies all reduce the risk.
Case study: the plugin nobody remembered
A UK professional training company with around 45 staff ran its website on a popular CMS, with course listings, a booking form and a members area for course materials. The site had been built by an agency four years earlier. After launch, the marketing team edited content, and the agency applied updates occasionally when asked. Nobody had a defined responsibility for security.
The first sign of trouble came from a customer, who emailed to say that clicking a search result for one of the company’s courses had taken them to an unrelated and suspicious site. Investigation found that an attacker had exploited a vulnerability in an events plugin installed during the original build, deactivated two years earlier but never removed. A fix for the vulnerability had been available for several months. The attacker had added hidden spam pages, a script that redirected some visitors arriving from search engines, and a new administrator account. Logs suggested the compromise had begun around ten weeks earlier.
The clean-up involved restoring clean files, removing the malicious account and content, updating everything, resetting all credentials, asking search engines to review the site and checking whether booking form data had been accessed — which, with advice, the company concluded it had not been. The site lost search visibility for several weeks.
Afterwards, the company introduced a hardening routine: an inventory, removal of eleven unused plugins and two old staging copies, multi-factor authentication for every administrator, individual accounts for agency staff, weekly managed updates with a monthly report, a cloud-based web application firewall, file change and administrator activity alerts to the marketing manager and the agency, and a quarterly access review. Over the following year, monitoring flagged two attempted logins from unusual locations and one vulnerable plugin, each handled within a day.
“We assumed that because the agency built the site, they were looking after its security. They assumed we would ask if we wanted that. Nobody was wrong exactly, but nobody was responsible. Now responsibilities are written down, and we hear about problems from our own monitoring rather than from customers.” — Marketing Manager, UK training company
The lesson is not that the platform or the agency was at fault. It is that a site without a named owner and a routine accumulates known weaknesses until one of them is used.
Common website security mistakes
The mistakes below recur across business sites of every type and size.
- Assuming the developer or agency handles security. Unless it is in a contract with defined tasks, it may not be happening.
- Leaving deactivated plugins installed. Remove anything not in use; on some platforms inactive code can still be exploited.
- Avoiding updates because one once broke the site. Use backups and staging to make updates safe rather than stopping them.
- Shared administrator logins. They make it impossible to remove one person’s access or trace who did what.
- No multi-factor authentication on admin accounts. The single most effective protection against stolen passwords, frequently missing.
- Treating a firewall as a substitute for patching. It reduces risk during gaps; it does not replace updates.
- Forgetting old sites and staging copies. Unpatched, unmonitored and often sharing credentials with the main site.
- Monitoring only uptime. Most compromises leave the site running; watch for changes, not just outages.
- Untested backups. A backup that cannot be restored, or that already contains the compromise, does not help.
- Letting marketing tags accumulate. Every third-party script is code running on your pages; review and remove those no longer needed.
If a site is compromised, restoring a backup without understanding how the attacker got in often leads to reinfection, because the original weakness remains. Backups may also contain the compromise if it began before they were taken. Identify and fix the route in, reset all credentials, check for added accounts and files, and consider whether personal data may have been affected, taking appropriate professional advice where needed.
The 12-point website hardening checklist
The checklist covers the essential hardening controls for a UK business website. Most can be in place within a month.
- Maintain an inventory. Platform, components, accounts, environments, subdomains and third-party scripts.
- Name an owner. One person or provider responsible for website security, with tasks written down.
- Set a patch cadence. Critical fixes within days, routine updates weekly to monthly, major upgrades planned.
- Remove what you do not use. Unused plugins, themes, libraries, scripts, staging copies and old sites.
- Turn on multi-factor authentication. For every administrator, plus hosting, registrar and file transfer accounts.
- Use individual, least-privilege accounts. No shared logins; the lowest role that does the job.
- Review access quarterly. Remove former staff, agencies and contractors promptly.
- Follow secure coding practices. Parameterised queries, contextual output encoding, server-side validation and code review for custom work.
- Put a web application firewall in front. Tuned to the site, with the origin restricted so it cannot be bypassed.
- Add security headers. HTTPS enforced, and a content security policy where practical.
- Monitor for change, not just downtime. File and content changes, admin activity, search engine notices and vulnerability alerts, sent to a named person.
- Back up and test restores. Backups stored away from the site, kept long enough to predate a slow-burning compromise, and restored in a test.
Where an agency, developer or hosting provider looks after your site, list these tasks in the agreement: who patches, how often, who receives alerts, who reviews access, how quickly security issues are addressed and what reporting you receive. Clear written responsibilities prevent the most common gap of all — each side assuming the other is handling security.
Who is responsible: you, your agency or your host
The case study above illustrates the most common governance gap in website security: responsibility split between several parties, each assuming another has it covered. Business sites are typically touched by an internal marketing team, a web agency or freelance developer, a hosting provider and sometimes a separate IT provider. Each has a part to play.
- Hosting provider. On managed hosting, usually the server operating system, web server software and sometimes platform core updates, backups and basic firewalling. On unmanaged hosting or a cloud server, often very little beyond the infrastructure itself. Check exactly what your plan includes.
- Agency or developer. Often the platform, plugins, custom code and dependencies, but only if contracted to maintain them. A build contract alone does not usually include ongoing security maintenance.
- Internal team. Typically content, user accounts for their own staff, and the decision about who does what. The business remains accountable for its website and any data it handles, whoever carries out the work.
- IT provider. Sometimes domain, email and DNS, which are closely linked to website security, and occasionally monitoring.
A short responsibilities table — each hardening task, who does it, how often, and how they report — resolves most of this. Our guide to website maintenance and updates covers what an ongoing maintenance arrangement should include.
If the worst happens: responding to a website compromise
Even well-hardened sites can be compromised. A short, agreed response plan makes the difference between a contained incident and a chaotic one.
Contain
Depending on what is happening, take the site offline or put up a maintenance page, particularly if visitors are being redirected or served malicious content. Preserve evidence — logs and a copy of the compromised files — before cleaning anything, as it will be needed to understand what happened.
Investigate and clean
Establish how the attacker got in, what they changed and what they could access. Fix the route in, restore clean files from a known good source, remove added accounts and content, update everything and reset every credential associated with the site, hosting, database and related services.
Consider data and obligations
If personal data may have been accessed — form submissions, customer accounts, bookings — the business may have obligations under data protection law, which can include reporting certain breaches to the Information Commissioner’s Office within 72 hours of becoming aware of them and, in some cases, informing affected individuals. Whether an incident must be reported depends on the circumstances, so take appropriate advice promptly. If card payments are involved, your payment provider’s requirements also apply. Cyber insurance policies often require early notification and may provide incident support, so check your policy terms.
Recover and learn
Bring the site back, request a review from search engines if they flagged it, and monitor closely for reinfection. Afterwards, review what allowed the compromise and which layer in this guide would have prevented or detected it sooner, and close the gap.
At a glance: website security hardening
| Layer | What it involves | How often | What it prevents |
|---|---|---|---|
| Inventory | Components, accounts, environments, subdomains, scripts | Reviewed quarterly | Forgotten, unpatched assets |
| Ownership | Named owner and written responsibilities | Ongoing | Gaps between agency, host and business |
| Critical patches | Security fixes for components in use | Within days of release | Exploitation of published vulnerabilities |
| Routine updates | Plugins, themes, libraries, platform | Weekly to monthly | Accumulation of known weaknesses |
| Component removal | Unused and abandoned add-ons and libraries | Quarterly | Vulnerabilities in code nobody uses |
| Multi-factor authentication | All admin, hosting and registrar accounts | Set once, checked quarterly | Logins with stolen passwords |
| Access review | Individual, least-privilege accounts | Quarterly | Misuse of old or excessive access |
| Secure coding | Parameterised queries, output encoding, validation, review | Every release | SQL injection and cross-site scripting |
| Web application firewall | Tuned rules, origin restricted | Reviewed periodically | Automated attacks during patch gaps |
| Security headers | HTTPS enforcement and content security policy | Set once, reviewed on change | Downgrade attacks; limits script injection impact |
| Third-party scripts | Inventory, controlled additions, restricted sources | Quarterly | Compromise through other providers |
| Change monitoring | File, content and admin activity alerts | Continuous | Long-running undetected compromises |
| Backups | Off-site, retained long enough, restore tested | Daily backups; annual restore test | Unrecoverable sites after an incident |
| Response plan | Contain, investigate, consider obligations, recover | Reviewed annually | Chaotic, prolonged incidents |
How Cloudswitched approaches website security
We build and maintain business websites with hardening designed in rather than added later. For new builds, that means keeping third-party components to those that are well maintained and genuinely needed, following secure coding practices — parameterised queries, contextual output encoding, server-side validation and code review — and putting multi-factor authentication, security headers and a web application firewall in place before launch.
For existing sites, we start with an inventory and security review, then work through a hardening programme like the one in this guide: locking down access, catching up on updates, removing unused components and forgotten assets, setting up a firewall and change monitoring, and reviewing custom code where there is any. We then agree an ongoing maintenance routine with clear written responsibilities, including the patch cadence, who receives alerts and what we report each month.
Where a site has already been compromised, we help contain and clean it, identify how the attacker got in and close the gap, and support you in working out whether any data obligations apply alongside your own advisers. No hardening programme can make a site immune to attack, but layered controls and early detection make compromises far less likely and far smaller when they happen.
Want a website that is not the easiest target?
Talk to us about a website security review, a hardening programme or ongoing secure maintenance for your business site.
Talk to a Web Development SpecialistFrequently Asked Questions
What is website security hardening?
The process of reducing a website’s attack surface and strengthening what remains: keeping software updated, removing unused components, protecting administrative access, writing and reviewing code securely, adding a web application firewall and security headers, and monitoring for signs of compromise. It is an ongoing routine rather than a one-off project.
How do most business websites get hacked?
Most commonly through outdated plugins, themes, extensions or platform versions with publicly known vulnerabilities, followed by weak or stolen administrator credentials. Forgotten sites, flaws in custom code and compromised third-party scripts account for a smaller share.
Is WordPress insecure?
The WordPress core is actively maintained and generally fixes security issues promptly. Most WordPress compromises involve outdated or poorly maintained plugins and themes, or weak administrator access, rather than the core itself. A well-maintained WordPress site with a modest number of reputable plugins can be reasonably secure.
How often should website plugins and software be updated?
Security fixes should be applied within days of release, sooner if a vulnerability is being actively exploited. Routine updates are commonly applied weekly or fortnightly for CMS sites and at least monthly for custom applications, with backups taken first and testing on a staging copy for business-critical sites.
Do I need a web application firewall?
For most business sites, a web application firewall is a worthwhile and inexpensive layer, particularly for blocking automated attacks and providing cover between a vulnerability being published and the site being patched. It should complement patching, access control and secure code rather than replace them.
How are XSS and SQL injection prevented?
SQL injection is prevented primarily by parameterised queries, which keep user input separate from database commands. Cross-site scripting is prevented primarily by encoding output appropriately for where it appears in a page. Server-side input validation and a content security policy add further layers. Modern frameworks support all of these when used as intended.
Does HTTPS make my website secure?
HTTPS protects data travelling between visitors and your site and is essential, but it does not protect the site itself from vulnerable software, weak passwords or coding flaws. It is one layer among several.
How would I know if my website had been compromised?
Without monitoring, often only when a customer, search engine or provider tells you. Content and file change monitoring, administrator activity alerts and search engine webmaster notifications give much earlier warning, as do signs such as unexpected redirects, new admin accounts or unfamiliar pages appearing in search results.
Who is responsible for my website’s security?
The business remains accountable for its website and any data it handles. Day-to-day tasks may be carried out by a hosting provider, agency, developer or internal team, but only those written into an agreement can be relied on. A clear list of responsibilities avoids gaps.
Do I need to report a website hack?
If personal data may have been accessed, data protection law may require the breach to be reported to the Information Commissioner’s Office within 72 hours of becoming aware of it, and in some cases affected individuals to be informed. Whether reporting is required depends on the circumstances, so take advice promptly. Payment providers and insurers may have their own notification requirements.
Should I have my website penetration tested?
For sites that handle personal data, payments, customer accounts or business-critical functions, an independent test after hardening is a sensible check, and some customers or frameworks may expect one. For simple brochure sites, regular vulnerability scanning combined with good maintenance is often proportionate.
How much does website security hardening cost?
Many of the most effective controls, such as multi-factor authentication, access review and removing unused components, cost little beyond time. Ongoing managed updates and monitoring for a typical business site might cost from tens to a few hundred pounds a month, and a security review or code review is usually a one-off fee depending on scope.
Related reading
More guidance on securing and running UK business IT:
Close the doors attackers actually use
Cloudswitched hardens and maintains business websites with patching on a defined cadence, protected admin access, secure code, a tuned firewall and monitoring that spots problems before your customers do.
Talk to a Web Development Specialist
CloudSwitched
London-based managed IT services provider offering support, cloud solutions and cybersecurity for SMEs.
