Website Security Essentials: SSL, Backups, and the Most Common Attack Vectors

A local bakery's booking site gets 40 visitors a day. Its owner assumed nobody would bother attacking it: there's no customer database worth stealing, no payment processor, nothing that screams "target." Six weeks after launch, the site was quietly serving malware to visitors and had been blacklisted by Google Safe Browsing. Nobody had "hacked" the business specifically. A bot had scanned millions of WordPress installs for a known plugin vulnerability, found this one, and dropped a payload. The owner never came up on anyone's radar as a person; the site came up as a match in a scan.

That's the part that's easy to miss when you're running a small business site: you're not being targeted, you're being scanned. Automated attack tools don't care how big your company is, how much traffic you get, or whether you feel like a "real target." They crawl the entire public web looking for specific, known weaknesses (an outdated plugin version, a default admin username, an unpatched CMS core file) and they exploit whatever they find, indiscriminately. In some respects, small business sites are easier targets than large ones precisely because they're less protected: no security team, no monitoring, no budget line for it, and often no one checking in until something visibly breaks.

This article covers the essentials of website security for small businesses: what SSL actually does, the attack vectors that most commonly hit small sites, how to back up in a way that will actually save you, and what a sane baseline security setup looks like. None of it requires an enterprise security budget. Most of it is disciplined basics, applied consistently.

SSL/HTTPS: what it actually protects

SSL (technically TLS now, but "SSL" stuck as the common term) is the encryption layer behind the padlock icon in a browser's address bar and the "https://" at the start of a URL. It does two specific things, and it's worth being precise about what they are:

• Encrypts data in transit. Anything sent between a visitor's browser and your server (form submissions, login credentials, page content) is scrambled so it can't be read or tampered with by anyone intercepting the connection, such as on public wifi.
• Verifies the site's identity. A valid certificate confirms that visitors are actually talking to your server, not to an impostor sitting in between (a "man in the middle" attack).

What SSL does not do is protect your server from being hacked, prevent malware, or secure your database. It's one layer, not a security system. But it's the layer that used to be optional and now isn't. A few years ago SSL was something you added for ecommerce sites handling payment details. Today, browsers actively flag any non-HTTPS site as "Not Secure" directly in the address bar, a warning label visible to every visitor before they read a word of content. Google has also confirmed HTTPS as a ranking signal, and PageSpeed/Core Web Vitals tooling increasingly assumes a secure connection as baseline. Running a site without SSL now costs you visitor trust and search visibility simultaneously, for a fix that's typically free and automated (Let's Encrypt certificates, auto-renewed by most modern hosts) and takes minutes to set up. There's no longer a good reason to skip it, on any site, including one with no forms and no ecommerce.

The attack vectors that actually hit small business websites

"Hacked" covers a wide range of scenarios, but for small business websites, the overwhelming majority of incidents trace back to a short list of known, well-understood vectors. Understanding them is most of the battle, because it turns "security" from an abstract worry into a specific, addressable checklist.

Outdated CMS core and plugin vulnerabilities

This is the single most common cause of small business site compromises, and it's almost entirely preventable. WordPress powers roughly 40% of the web, which makes it, and its plugin ecosystem, a constant target for vulnerability research, both legitimate and malicious. When a security flaw is found in a popular plugin, it's disclosed publicly (often with a patch released alongside it), and within days automated scanners are probing the entire web for sites still running the vulnerable version. If a plugin, theme, or CMS core hasn't been updated, the vulnerability is public knowledge and the exploit is often just as public. This isn't a sophisticated targeted attack, just a bot checking a version number.

Weak or reused admin passwords

Credential stuffing (trying username/password combinations leaked from other breaches against your login page) works surprisingly often, because people reuse passwords across services. An admin password that's also used on some unrelated forum or app that got breached years ago is a live risk today, silently, until someone tries it against your site.

Brute-force login attempts

Related but distinct: automated tools simply try large volumes of common passwords and username combinations against a login form, no leaked-credential list required. Default usernames like "admin" combined with a login page that never locks out after failed attempts make this trivially easy to run at scale, and it's run against essentially every publicly known CMS login URL on the web, constantly.

SQL injection and cross-site scripting (XSS)

These matter most for custom-coded sites and applications rather than off-the-shelf CMS installs (though poorly coded plugins can introduce them too). SQL injection exploits improperly sanitized database queries to let an attacker read, modify, or delete data they shouldn't have access to. XSS injects malicious scripts into pages viewed by other users, often via a comment field, search box, or any input that isn't properly escaped before being rendered back to the browser. Both are well-understood, decades-old vulnerability classes with established prevention techniques (parameterized queries, input sanitization, output encoding); they persist mainly in code that wasn't reviewed with security in mind.

Malicious file uploads

Any feature that lets users or admins upload files (image uploads, document submissions, resume forms) is a potential vector if the server doesn't strictly validate what's actually being uploaded. An attacker who can get a script file onto your server, disguised as an image or document, and get the server to execute it, effectively gets a foothold inside your site.

Compromised third-party plugins and scripts

Not every compromise starts with your own configuration. Analytics snippets, chat widgets, ad scripts, and plugins pull code from third-party sources. If one of those third parties gets compromised upstream, that malicious code can flow into every site using it: a supply-chain problem rather than a direct attack on you. This is a good argument for keeping the number of third-party scripts and plugins on a site as small as genuinely necessary.

Backups done properly (not just assumed)

Every one of the vectors above can, in the worst case, end with a site that's defaced, wiped, or held for ransom. When that happens, the single factor that determines whether it's a bad afternoon or a business crisis is whether a clean, working backup exists. And the word "working" is doing a lot of heavy lifting in that sentence, because a shocking number of "we have backups" setups turn out not to work when actually needed.

A backup strategy that will genuinely protect you has four properties:

• Automated. If it depends on someone remembering to run it manually, it will eventually not happen, usually right before it's needed.
• Regular. Frequency should match how often content and data change. A static brochure site might be fine with weekly backups; an ecommerce store taking orders daily needs at least daily, ideally more frequent for the order database.
• Stored off-server. A backup stored on the same server as the live site is not a real backup: if that server is compromised, wiped, or the host has an outage, the backup goes down with it. Off-site storage (a separate cloud storage provider, a different infrastructure account entirely) is what makes a backup actually resilient.
• Tested, not assumed. This is the step almost everyone skips, and it's the one that matters most. A backup file existing is not the same as a backup that restores cleanly. Database exports can be partial, file backups can miss directories, restore scripts can silently fail. The only way to know a backup actually works is to periodically perform a real test restore (ideally to a staging environment) and confirm the result is a fully functioning site, not just a folder of files that looks right.

We've seen the failure mode this guards against play out directly: a business owner discovers a compromise, goes to restore from backup, and finds the backup job had been silently failing for months due to a changed API key nobody rotated in the backup config. The backups looked fine in a dashboard that only checked "did the job run," not "did it produce something restorable." A quarterly test restore would have caught it in week one.

A practical baseline security checklist

None of the following requires specialist security expertise. It's discipline, applied consistently, and most of it can be set up once and then maintained as routine.

• Strong, unique admin passwords plus two-factor authentication. A password manager removes the excuse for reuse; 2FA means a leaked or guessed password alone isn't enough to get in.
• Keep software updated. CMS core, themes, and plugins, on a defined schedule, not "whenever someone remembers." This closes the single biggest vector covered above.
• A web application firewall (WAF). Filters malicious traffic (known exploit patterns, bad bots, common injection attempts) before it reaches your site. Many hosts and CDN providers offer this as a built-in or low-cost add-on.
• Limit login attempts. Lock out or rate-limit after a handful of failed logins. This alone neutralizes most brute-force attempts.
• Minimal plugin footprint. Every plugin is additional attack surface and an additional thing that needs updating. Audit periodically and remove anything not actively earning its place.
• Regular security scans. Automated malware and vulnerability scanning catches problems early, often before they're visible to visitors or search engines, which matters because Google blacklisting a compromised site tends to happen fast and de-listing takes real time to reverse.

This is exactly the kind of list that's easy to write down and hard to keep current without someone actually owning it. We covered why ongoing attention matters more than a one-time setup in our piece on website maintenance as insurance for your business, which looks at security as one piece of a broader maintenance picture; this article is the deeper dive into the security side specifically.

What to do in the first hour if you suspect a breach

If something looks wrong (unfamiliar admin users, unexpected files, a Google Safe Browsing warning, visitors reporting strange redirects, a defaced page), the first hour matters more than any other. Panic and improvisation tend to make things worse; a short, calm sequence tends to contain the damage.

1. Take the site offline or into maintenance mode if you can do so quickly, to stop further damage or spread to visitors. If you can't take it fully offline, at minimum disable public file uploads and any obviously exposed forms.
2. Change all admin passwords immediately (CMS admin, hosting control panel, FTP/SFTP, database) from a device you're confident is clean. Assume the ones you had were compromised.
3. Preserve evidence before you clean anything up. Copy suspicious files, note timestamps, check server access logs for unusual activity. This matters both for understanding how the attacker got in (so you close that door specifically) and, if needed, for reporting to your host or authorities.
4. Check your backup situation before you do anything destructive. Confirm you have a clean, pre-compromise backup available and roughly how far back it goes, before deciding on a restore-versus-clean approach.
5. Restore from a known-clean backup rather than trying to manually remove malicious code file by file. It's easy to miss a backdoor left behind, and a clean restore is far more reliable than a manual cleanup under time pressure.
6. Identify and close the actual entry point before bringing the site back fully live. Restoring a backup without fixing the vulnerability that let the attacker in the first time just resets the clock until it happens again.
7. Request a malware review from Google Search Console (or the relevant browser/blacklist authority) once you're confident the site is clean, so any "This site may be hacked" warning gets lifted as quickly as possible.

Having this sequence written down and agreed on before an incident happens is worth far more than remembering the right steps under pressure at 11pm on a Friday.

Website security isn't a one-time setup you check off and forget. It's an ongoing practice of updates, monitoring, and tested backups, the same way locking your office door every night is a habit rather than a one-time decision. If you'd rather have this handled as a standing part of how your site is looked after, our website maintenance service covers exactly this: SSL and update management, backups that are actually tested, security monitoring, and a fast, practiced response if something does go wrong. Feel free to get in touch if you want a second opinion on where your current setup stands.