Most website compromises aren't the result of a determined attacker specifically targeting one business — they're the result of automated scanning that continuously probes the internet for a short list of well-known, avoidable weaknesses, and finds one. The mistakes below account for the overwhelming majority of real-world incidents, and every one of them has a specific, practical fix.

Running outdated software

A CMS, plugin or server software with a known, published vulnerability is one of the most common ways a site gets compromised, precisely because the vulnerability is public and automated tools scan for it specifically. The fix isn't complicated in principle — apply updates promptly — but in practice it's the most commonly skipped maintenance task, usually out of fear that an update will break something. The more reliable approach is testing updates on a staging copy before applying them to production, rather than avoiding updates altogether, which trades a small, manageable risk (an update causing an issue that can be rolled back) for a much larger one (a known, unpatched vulnerability sitting exposed indefinitely).

Weak or reused credentials

An admin password that's weak, or reused from another account that's been compromised elsewhere, remains one of the most direct paths into a site — credential-stuffing attacks specifically try passwords leaked from unrelated breaches against every login form they can find, on the reasonable assumption that some fraction of people reuse passwords. A unique, sufficiently long password per account, generated and stored with a password manager rather than remembered, closes this off almost entirely without requiring anything more sophisticated.

No multi-factor authentication on admin accounts

Even a strong password can be compromised — through phishing, a breach at an unrelated service, or malware on an admin's own device. Multi-factor authentication (MFA) means a stolen password alone isn't enough to log in, since a second factor — a code from an authenticator app, most commonly — is also required. This is a disproportionately effective control relative to how simple it is to set up, and it's one of the highest-leverage items on this list: enabling it on every administrative account (CMS admin, hosting control panel, domain registrar) closes off the majority of account-takeover attempts that a strong password alone wouldn't stop.

Unrestricted file uploads and permissions

A form that accepts file uploads — a contact form attachment, a profile picture, a document submission — without restricting file type and without storing uploads outside the directly web-accessible path is a common route for an attacker to place executable code directly on the server. The practical fixes are specific: validate both the file extension and the actual file content (not just trusting the extension a browser reports), store uploads in a location the web server won't execute as code, and set file and directory permissions to the minimum the application actually needs rather than defaulting to broad, permissive access because it's easier during development and never revisited before launch.

No tested backup strategy

A backup that's never been tested isn't a reliable backup — it's an assumption. The common failure isn't the absence of backups entirely, it's discovering during an actual incident that the backup job had been silently failing for weeks, or that a restore doesn't actually work the way it was assumed to. A workable baseline is the 3-2-1 approach: at least three copies of the data, on two different types of storage, with at least one copy stored offsite or with a separate provider — combined with periodically actually restoring from a backup to confirm it works, not just confirming the backup job completed without an error. See How Website Backups Work for what full, incremental and differential backups actually do, and How Often Should You Back Up a Business Website? for how to reason about backup frequency specifically.

Treating HTTPS as optional or a checkbox

HTTPS is necessary but not sufficient — a valid certificate protects data in transit and confirms domain ownership, but it says nothing about the security of the application behind it. The common mistake here isn't skipping HTTPS entirely anymore (it's rare not to have some certificate installed), it's treating the padlock icon as proof that "the site is secure" in a general sense, which leads to under-investing in the other items on this list because the padlock creates a false sense of completion. See SSL Certificates Explained for exactly what a certificate does and doesn't cover.

How attackers actually find these mistakes

It's worth understanding the mechanism, because it explains why "we're too small to be a target" is a common but mistaken assumption. Most compromises don't start with a person deliberately choosing a specific business to attack — they start with automated tools continuously scanning large ranges of the internet for sites running a specific vulnerable software version, an exposed admin login page, or an open port that shouldn't be reachable. A newly launched site with an outdated plugin can be found and probed within hours of going live, not because anyone targeted it specifically, but because it matched a pattern the scanning tool was already looking for across millions of sites simultaneously. This is precisely why the mistakes on this list matter regardless of a business's size or profile: the attacker isn't evaluating whether a target is "worth" attacking in advance, they're running the same automated check against everything reachable, and reacting to whatever it finds.

What happens after a compromise, and why prevention is cheaper

A compromised site is rarely just a one-time inconvenience to clean up. Common consequences include the site being used to host malware or phishing pages targeting the business's own visitors, search engines flagging and de-indexing the site once it's identified as compromised, email deliverability being damaged if the same server is used to send spam, and — for a business handling any customer data — a legal or regulatory disclosure obligation depending on what was exposed. The cleanup itself typically costs more in time and specialist effort than the preventive measures would have, and some damage — search ranking recovery, customer trust, deliverability reputation — takes considerably longer to repair than the technical fix does. This asymmetry is the practical argument for treating the checklist below as a baseline cost of running a business site, not an optional enhancement to get to eventually.

A practical baseline checklist

A reasonable minimum standard, roughly in order of impact relative to effort:

  • Keep the CMS, plugins and server software updated, testing on staging first where practical.
  • Use unique, strong passwords for every administrative account, managed with a password manager.
  • Enable multi-factor authentication on every admin login — CMS, hosting panel, domain registrar.
  • Validate and restrict file uploads, and store them outside the directly executable web path.
  • Maintain and periodically test backups following a 3-2-1 approach.
  • Install a valid SSL certificate site-wide, and treat it as one control among several, not the whole solution.

None of these individually guarantees a site is safe from every possible attack — security is a matter of reducing risk and closing off the well-known, high-probability paths, not eliminating risk entirely. But this specific list accounts for the overwhelming majority of real-world compromises, which makes it a disproportionately effective place to start. Treat it as a baseline to revisit periodically, not a one-time setup task — software gets updated, staff and access needs change, and a checklist that was fully addressed at launch can quietly drift out of date over a year or two without anyone deciding to skip it.