Website Security: How Sites Get Hacked and How to Stop It

Why Even Small Sites Get Attacked

Let's start with the belief we hear in almost every first meeting: "Who would bother with us? We have five pages and get three enquiries a week." It sounds reasonable. It is also exactly why sites like that get compromised most often.

Nobody picked you. The overwhelming majority of attacks against small and mid-sized businesses aren't personal at all. Software does the work: it takes lists of domains and IP addresses, walks through them one by one, and tests each for dozens of known weaknesses. The bot has no idea whether you're a dental clinic or a ceramics studio. It reads a version string in the server response, checks its list, and moves on if there's no match. If there is a match, it goes to work.

It's the equivalent of walking down a street pulling car door handles. Nobody chose your car. Yours was just unlocked.

What a Brochure Site Is Even Worth

An attacker almost never wants to hurt you specifically. A compromised site has a market value, and it comes from several things at once:

• Link equity. Hidden links or entire hidden sections about casinos, loans, or pharmacies get quietly injected into your pages. You don't see them. Search engines do.
• Traffic. Your visitors get redirected elsewhere — but not all of them. Often only mobile users, only those arriving from search, and only once per day per person. That's precisely why you can visit your own site from your own laptop for months and notice nothing.
• Server resources. Your hosting becomes a node for sending spam, mining, or attacking other sites.
• Data. A database of enquiries, phone numbers, addresses, and emails is a product with buyers. Even if all you have is "just a contact form".
• Extortion. Files get encrypted or deleted, and you're invited to pay for their return.

Which leads to the conclusion that changes how this whole topic feels: website security isn't about defending against a genius in a hoodie. It's hygiene that moves you out of the easy-target pool. A bot won't spend time on a well-kept site while a thousand neglected ones sit next door.

How Owners Usually Find Out

The symptoms almost never come from you. Your host emails about suspicious activity. Google Search Console flags a warning. A client calls to say their browser is shouting at them. Company email suddenly lands in everyone's spam folder. Search traffic drops with no explanation. If any of that has happened, you found out late — but late is not the same as too late.

How Sites Actually Get Compromised

Forget the movies. In reality, nearly every small-business compromise traces back to a short and remarkably boring list. We've cleaned up dozens of infected sites, and the entry point was almost always one of these.

Outdated CMS, and Plugins Above All

This is the runaway winner. WordPress, Joomla, OpenCart — the platforms themselves aren't inherently leaky. The ecosystem is the problem: a gallery plugin last updated in 2021, a theme bought on a marketplace whose author moved on years ago, a form module a contractor installed and forgot.

Understand the mechanics here, because they're counterintuitive. When a vulnerability is found in a plugin, it gets published. That's how the industry works, and it's correct. But from that moment a race begins: the developer ships a fix, and scanning bots receive the fingerprint of the vulnerable version within hours. A site that updates once a year isn't in that race at all.

Weak Passwords, and Far Worse, Reused Ones

A password like Admin2024! feels strong — capital letter, digits, an exclamation mark. It's in every cracking dictionary. But that isn't the real damage. The real damage is the same password on your hosting panel, your site admin, your email, and some service that got breached two years ago. Someone else's leak becomes your login, and technically no "hacking" happens at all. The attacker simply types a username and a password.

Credentials Stolen From a Staff Laptop

The classic nobody suspects. FTP credentials saved in a file manager on a designer's laptop get read by ordinary commodity malware. The site is "hacked" through a legitimate login. The tell-tale sign: you clean everything thoroughly and the infection is back within two days.

Unprotected Forms and Open Endpoints

Every place your site accepts input from outside — a contact form, site search, a file upload, an API endpoint — is a door. When input is accepted without checking its type, size, and contents, the door works in both directions. File upload deserves special fear: allowing someone to place something on your server that the server later executes is essentially handing over the keys.

Files Left Lying in the Web Root

The quiet killer, and we find it constantly. Living in the public folder: backup.zip from the previous agency, dump.sql with the full database, a .git folder containing the entire project history with passwords in old commits, a test.php, an info.php, a config copy named config.php.bak. Every one of those is downloadable by anyone who guesses the URL. And bots don't guess — they carry lists of the usual names and check them in seconds.

A word specifically about .bak and .old extensions: the server doesn't execute those as code, it serves them as plain text. Meaning it hands your database password straight to the browser.

Forgotten and Abandoned Projects

An old campaign landing page on a subdomain. A staging copy built two years ago and never removed. A forum nobody uses. They never get updated because nobody remembers they exist. And they usually sit in the same hosting account — so compromising a forgotten landing page hands over the files of your main site. We open every audit with "what else lives in this account?", and the answer regularly surprises the owner more than anyone.

HTTPS and SSL: No Longer Up for Debate

If you don't have HTTPS, stop reading and fix that first. In 2026, a site without encryption isn't thrift. It's a fault.

What an SSL Certificate Actually Does

Without HTTPS, data travels between your visitor's browser and your server in plain text. Anyone positioned along that path can read it and change it: the café Wi-Fi owner, an ISP, equipment on an intermediate network. Reading it means reading passwords and form contents. Changing it means they can rewrite your page or inject their own ads into it, and your visitor will be certain it came from you.

An SSL certificate solves two problems at once. It encrypts the channel, and it proves the domain belongs to whoever is serving it. The second matters as much as the first: without identity, encryption is pointless, because you might be encrypting a channel to a fraudster.

The Details That Matter More Than the Certificate Itself

Certificates are free and automatic now — Let's Encrypt settled that question for everyone. So the mistakes are no longer about "have one or not". They're in the configuration:

• Redirects. Every HTTP request must permanently redirect to HTTPS. Otherwise the old version simply keeps running alongside the new one.
• Mixed content. The page loads over HTTPS but pulls an image, font, or script over HTTP. The browser complains and the padlock disappears. Old analytics snippets and third-party widgets are the usual culprits.
• Auto-renewal. Certificates are short-lived and renewed by a robot. When the robot breaks, you'll hear about it from customers on the worst possible day. Monitor the expiry date.
• Canonical URLs. After moving to HTTPS, make sure each page has one address rather than four variations with and without www.

What HTTPS Doesn't Do

Here lives a dangerous misconception. The padlock does not mean the site is safe. It means exactly one thing: the channel to the server is encrypted. A compromised site full of malicious code serves happily over HTTPS with the padlock intact. Phishing sites have certificates too — they're issued free and automatically to everyone. HTTPS is a foundation, not a roof.

For sites that handle money, the bar is far higher. Channel encryption is the entry ticket; after that come webhook signature verification, idempotent operations, and strict separation of access. We walked through that machinery in detail using the Payora payment gateway, where transaction security outranks every other feature in the build.

Security Headers: The Quiet Defence Nobody Turns On

Security headers are instructions your server sends to the browser alongside the page. The point is that browsers are trusting by default: they'll run any script they find on your page and display your page inside someone else's window if asked. Headers are how you tell the browser, "don't do that with me."

Their great virtue is that they're free, configured once, and enforced on the visitor's side without loading your server. Their great problem is that they're absent by default almost everywhere.

Content-Security-Policy (CSP)

The most powerful and the most temperamental. It's an allowlist: where this page may load scripts, styles, images, and fonts from. If an attacker manages to inject a foreign script into your page, the browser simply refuses to execute it, because the source isn't on the list. In effect, CSP turns a successful compromise into a failed one.

An honest warning: rushing CSP will break your site. The right path is report-only mode first, collect the violations, then tighten. On a site with a dozen third-party widgets that's several days of work, not ten minutes.

Strict-Transport-Security (HSTS)

Tells the browser: this domain is HTTPS-only, remember that for a year. It closes the gap between someone typing an address without a prefix and the redirect firing. That gap is precisely where interception happens. Only enable it once you're confident HTTPS works everywhere and permanently — reversing the decision is slow.

X-Frame-Options

Stops your site being embedded in a frame on someone else's page. It defends against a simple, nasty trick: an invisible layer placed over your real button, so the user's click goes somewhere they never intended. For any site with a customer account or a checkout, this one is mandatory.

X-Content-Type-Options

One line, no configuration. It forbids the browser from guessing a file's type against what the server declared. Without it, an uploaded image can, under the right conditions, be interpreted as a script and executed.

Referrer-Policy

Controls what information about your site the browser passes along when a visitor clicks away. Without it, the full page URL — including parameters like a password-reset token or an internal identifier — travels into someone else's analytics. That isn't a hack. It's a leak: quiet and continuous.

Permissions-Policy

Switches off what your site plainly doesn't need: camera, microphone, geolocation, sensors. The rule is simple — anything unused should be off.

Any public online scanner will grade your headers in a minute, and the result is usually sobering. For us, headers are part of the base build on every project — part of development itself, not a paid extra bolted on later.

Updates and Third-Party Code: Discipline Over Heroics

The advice is boring: keep things updated. The problem is that it's the one piece of advice everyone has heard and almost nobody follows. Let's look at why — and how to make it stick.

Why Updates Get Postponed

Not laziness. Fear. An update once broke the layout, or the cart stopped working, and the "update" button has been avoided ever since. The fear is rational: updates genuinely can break things, especially when a site is assembled from plugins that were hacked about directly in their source.

But do the arithmetic. The risk of a broken layout costs you an hour. The risk of a compromise costs you a restore, a cleanup, awkward conversations with customers, and months of clawing back search rankings. The second risk is an order of magnitude more expensive.

How to Update Without Panic

1. Back up before, not after. Full backup: files and database. Never skip this step, no exceptions.
2. Keep a staging copy. A separate environment, closed to search engines and outsiders, where updates get tested before they go live. On any serious project this isn't optional.
3. Separate critical from routine. Security updates go on immediately. Minor ones on a schedule. Major version jumps are their own project with a plan.
4. Check the important things after. Submit a form, run a payment, log into an account, look at it on a phone. Three minutes of manual checking saves weeks.

Auditing Other People's Code

Once a quarter, open your plugin list and ask two questions. First: is this used at all? A plugin installed "just in case" is a hole with no function. And note that a deactivated plugin still sits in the file system and can still be vulnerable — so unused things must be deleted, not switched off.

Second: is the author alive? If the last update was three years ago and the description says it's compatible with a version that's long obsolete, that's abandoned code. It will not get safer on its own. Find a replacement calmly, in advance, rather than on the night after a compromise.

And the rule worth framing on the wall: the less third-party code on your site, the smaller your attack surface. Every plugin is a stranger you have silently granted access to your server.

Access and Hosting Hygiene: Bigger Wins Than Code

The most common real-world cause of a compromise isn't a clever exploit. It's scattered access. This is also where order gets restored fastest and for almost no money.

Least Privilege

Every person and every process should hold exactly the rights their job requires and not a drop more. A content manager doesn't need administrator rights; they need to publish articles. A contractor editing one page doesn't need the database. A script that reads a catalogue doesn't need write access.

Open your admin user list right now. In audits we routinely find live accounts belonging to people who left, an agency you parted ways with a year ago, and a mysterious user called admin2 that nobody can account for. That last one isn't an oversight — it's a symptom.

One Account Per Person

A shared admin login with the password sitting in a chat thread means nobody is accountable. When something happens, the log says "admin logged in", which tells you precisely nothing. Individual accounts buy you two things: a readable history of who did what, and the ability to revoke one person's access without changing passwords for the whole company.

Two-Factor Authentication

If you implement exactly one item from this entire article, make it this one. 2FA makes a stolen password worthless. Every brute-force attempt and every third-party breach stops working against you, because the password alone is no longer enough. Turn it on everywhere it exists: hosting panel, domain registrar, site admin, email, Cloudflare, GitHub.

A special word about the domain registrar. It's the most underrated point of failure in the entire stack. Losing control of your domain is worse than losing your site: a site restores from backup in an hour, while a domain comes back over months of support tickets — if it comes back.

SSH Keys Instead of Passwords, and No FTP

A password can be guessed or lifted from a laptop. A key cannot be guessed in any useful timeframe. Setup takes fifteen minutes once, after which password login to the server is disabled entirely.

Separately: drop plain FTP. It sends your username and password in clear text, like it's 1998. Use SFTP or SSH only. If your host offers FTP as the primary method, that tells you something about the host.

A Password Manager Instead of Memory

No human can remember forty distinct complex passwords, which is exactly why they reuse them. A password manager removes the problem entirely: it generates a unique password per service, stores them encrypted, and lets you hand credentials to a colleague without pasting them into a messenger. It costs pocket change and prevents a catastrophe.

Forms, Spam, and Rate Limiting

The contact form is the most accessible part of your website. It's open to everyone, works without login, and sits there waiting for data. No wonder it takes the most abuse.

Why CAPTCHA Isn't the Answer

CAPTCHA catches primitive scripts and annoys real humans. Modern spam traffic gets past it either technically or through solving services where actual people answer captchas for fractions of a cent. Meanwhile it measurably hurts conversion: some genuine customers simply give up on the distorted letters and leave.

The approach that works is layered and invisible to the visitor:

• Honeypot. A hidden field a human never sees or fills, and a bot fills automatically. Filled means discarded. Simple, free, effective against the bulk of it.
• Timing checks. A form submitted half a second after the page loaded was not filled in by a person.
• Rate limiting. No more than a few submissions from one address in a given window. This is the key mechanism, and the same one protects your login page from password guessing.
• Invisible scoring. Modern systems assess behaviour and only challenge requests that look suspicious. A real customer sees nothing at all.

Server-Side Validation Is Non-Negotiable

Elegant field validation in the browser is a convenience for users, not a defence. Data arriving at your server can be sent without ever touching your page. So everything gets checked again server-side: type, length, format, allowed values. The rule is simple and universal: input from the outside world is never trustworthy, even if your own script validated it a moment ago.

File Uploads Are Their Own Problem

If a visitor can upload a file, behave as if they're uploading something hostile. Check the real content type, not the extension in the name. Rename the file yourself. Cap the size. And most importantly, store uploads somewhere the server physically will not execute code — ideally on separate storage entirely.

Rate Limiting Goes Beyond Forms

The same mechanism belongs on your API endpoints, site search, password reset, and any expensive operation. Without it, one persistent bot takes your server down through sheer repetition. It matters most where money is involved: on payment projects we always cap how fast transactions can be created — our piece on accepting crypto payments explains why that protects your accounting as much as your server.

Backups: The One Insurance Policy That Always Pays Out

Plainly: backups matter more than everything else in this article. Every other measure lowers the probability of disaster. Backups decide how the disaster ends — an unpleasant evening, or a closed business.

The 3-2-1 Rule

A classic invented long before us and still unbeaten:

• 3 copies of your data: the live one and two backups.
• 2 different media or platforms — not everything in one basket.
• 1 copy off-site, physically and administratively separate from the server.

That last point is where most setups collapse. A backup sitting on the same server, or in the same hosting account, is not a backup. An attacker who gets in deletes it first — that's a standard step, not a flourish. Ransomware encrypts it along with everything else. And if the host dies, it dies too.

An Untested Backup Is Not a Backup

Here's the part that stings. We keep seeing the same scene: backups ran faithfully for two years, and on the day it counts the archives turn out to be corrupt. Or they contain files but no database. Or the database is there, but the export mangled the encoding and the text is question marks. Or the archive is 40 kilobytes because the script died on the first folder and the error email went to an inbox nobody reads.

The conclusion: restores must be rehearsed. Once a quarter, deploy a copy to a staging environment and look at it. Does the site load? Is the database there? Are the images present? Do the orders show up? It's the only way to learn the truth about your backups in advance rather than during a catastrophe.

Retention Beats Frequency

A daily backup with three days of retention is useless against a quiet infection. Malicious code often sits dormant for months. By the time you find it, all three copies are already infected. Keep depth: daily for two weeks, weekly for a couple of months, monthly for a year. Disk space is incomparably cheaper than a site with nothing to restore from.

What to Back Up

Files and database are obvious. What gets forgotten is everything else: server configuration, web server rules, scheduled jobs, DNS settings, email. A good gauge is the question, "if the hosting company vanished tomorrow, how long would a full rebuild somewhere else take?" If you don't have an answer, your backup is incomplete.

Monitoring and Logs: See It Before Your Customer Does

Compromises are rarely loud. Far more often they're quiet, and that's the entire point: the longer you don't notice, the longer the asset earns money for whoever took it. So the job of monitoring isn't to "catch a hacker". It's to shorten the gap between the event and your knowing about it.

The Minimum Set

• Uptime monitoring. An availability check every minute with an alert. Basic services are free and take ten minutes to set up.
• File integrity monitoring. The system records the state of your files and tells you when something changes. Nobody touched the code, yet two files changed at 3 a.m. — that's a conversation.
• SSL and domain expiry. Alerts in advance, not afterwards. A forgotten domain renewal hurts more than most hacks.
• Google Search Console. Free and mandatory. Search engines often spot an infection before the owner does, and they'll say so plainly in the security section.
• External malware scanning. Regular checks from the outside catch what only a visitor sees: redirects, injected scripts, swapped content.

Logs: Boring, and Where the Truth Lives

Web server logs record every request to your site. On a calm day, nobody wants them. On the day of an incident, they're your only source of facts: when, from where, what exactly was requested, and what the server answered.

Two things are worth doing in advance, because they cannot be done retroactively. First, confirm logs are actually being written and kept for at least a month. In plenty of setups they're truncated after 24 hours, and there's nothing left to investigate. Second, enable admin login logging — successful and failed. A spike in failures is password guessing happening live, and you can respond before it succeeds.

What to Look For

You don't need to be an analyst to spot the obvious. Requests for files you don't have and never had. Admin requests at 3 a.m. from a country where you employ nobody. One address making hundreds of requests in a minute. A surge of error responses where there weren't any before. None of these is proof on its own, but each is a reason to look closer.

We include baseline monitoring in every project we support after launch — examples of that work sit in our portfolio. The lesson is unglamorous: a site nobody watches will eventually produce a surprise, and the surprise always costs more than the watching.

WAF and CDN: What Cloudflare Does and Doesn't Do

Cloudflare and services like it are a genuinely useful layer, which is exactly why so much mythology surrounds them. Let's be honest about where the value is and where the illusion starts.

What They Are

A CDN puts a network of nodes worldwide between your visitor and your server. Static files are served from the nearest node — the site is faster and your server is relieved. A WAF (web application firewall) is a filter that inspects incoming requests and discards attack-shaped ones before they reach your code.

The Real Value

• Absorbing DDoS. Junk traffic breaks against the provider's network rather than your server. A small business will not survive that attack alone.
• Hiding your real server IP. Direct attacks get harder when the target isn't visible.
• Bot filtering. A large share of scanning noise is dropped automatically, and your logs become readable overnight.
• Virtual patching. A WAF rule can hold a fresh vulnerability shut while you prepare a proper update. That's borrowed time, not a fix.
• Speed. A pleasant side effect that visitors and search engines both notice.

What They Won't Do

Now the uncomfortable half. A WAF will not save you when:

• Your password was stolen. A login with valid credentials is a legitimate request. The filter passes it through, and it's right to.
• Your real IP is already known and your server accepts connections directly, bypassing the filter. This is an extremely common misconfiguration: your server must accept traffic only from the provider's network.
• The flaw is in your own business logic. If your code lets one user fetch another user's order by changing a number, that's a perfectly well-formed request as far as the WAF is concerned.
• Malicious code is already inside. The filter watches the front door, not what's happening in the house.
• Encryption is set to "flexible". Then the leg from Cloudflare to your server travels in plain text while your visitor sees a padlock and assumes all is well. That's a dangerous imitation of security — use strict mode with certificate validation.

In short: a WAF and CDN are an excellent perimeter fence. A fence is useless when the key is under the mat and a ground-floor window is open. It complements hygiene. It doesn't replace it.

What to Do If You're Already Compromised

Stay calm. Panic costs more than the hack itself: in a panic people delete the very things an investigation needs. The procedure is well established. Follow it.

1. Isolate

Put the site behind a maintenance page returning a 503 status. That protects visitors from infection and tells search engines the outage is temporary rather than terminal. Don't delete anything yet.

2. Preserve the Evidence

Counterintuitive but critical. Take a full copy of the infected site plus the last month of logs before any cleanup. If you restore from backup without identifying the entry point, you'll be compromised again the same way, usually within a week. That copy is your only chance to understand how they got in.

3. Rotate Every Credential

All of them, no exceptions, no "that one definitely couldn't have leaked". Hosting, SSH, database, every admin user, FTP, domain registrar, email, connected services. Turn on 2FA everywhere it was missing while you're there. One caveat that people miss: do this from a clean computer. If the laptop is infected, your new passwords leak exactly like the old ones.

4. Find the Entry Point

Start with files modified on the date of infection — the fastest trail there is. Search the logs for what request arrived shortly before the first foreign file appeared. Check everything in the hosting account, including forgotten subdomains. Check the computers of everyone with access. Until the entry point is found, the incident is not closed.

5. Rebuild

The best route is a clean reinstall: fresh CMS, fresh plugins from official sources, and only your content and database taken from the backup — with the database checked first, because code gets injected there too, usually into templates and settings. Manually cleaning infected files is a lottery: miss one single file and the whole thing comes back.

6. Close the Hole and Recover Your Reputation

Fix the cause you identified, or you've simply reset the clock. Then: request a review in Google Search Console, check your domain's mail records (a compromised site was probably sending spam, and your domain may already be on blocklists), and confirm there are no unfamiliar administrators left in the database.

One honest note: if your site takes payments or stores customer personal data, improvising is the wrong call. You want someone who has done this before — get in touch. We handle incidents like these, and more importantly, we explain afterwards exactly what went wrong and how to make sure it doesn't recur.

A Practical Security Checklist

Let's compress all of the above into a list you can start on today. It's ordered by effect relative to effort — begin at the top.

Today, in One Evening

1. Turn on 2FA for hosting, your domain registrar, email, and the site admin.
2. Verify HTTPS works everywhere and all HTTP redirects to it.
3. Open your admin user list and remove everyone who shouldn't be there: former staff, old contractors, accounts nobody recognises.
4. Check the web root for stray files: archives, database dumps, a .git folder, config copies, test scripts.
5. Confirm backups exist and are not stored on the same server.
6. Connect the site to Google Search Console and read the security section.

This Week

1. Set up a password manager and replace every reused password with a unique one.
2. Update the CMS and all plugins, after taking a full backup.
3. Delete unused plugins and themes — delete, not deactivate.
4. Configure security headers: start with X-Content-Type-Options, X-Frame-Options, and Referrer-Policy, which are safe to enable immediately.
5. Disable FTP and move to SSH keys.
6. Add uptime monitoring and alerts for SSL and domain expiry.
7. Rate-limit login attempts on the admin panel.

This Month

1. Test a restore on a staging environment — actually deploy it and look at it.
2. Put a CDN and WAF in front, and close direct access to the server so nothing bypasses the filter.
3. Roll out CSP, starting in report-only mode.
4. Audit everything in the hosting account: subdomains, staging copies, forgotten landing pages. Delete what isn't needed.
5. Set up file integrity monitoring.
6. Review file and folder permissions, removing write access wherever it isn't required.

On Repeat, So You Never Need This Article Again

• Weekly: security updates, a glance at the login log.
• Monthly: verify backups, review users, skim the logs.
• Quarterly: test restore, audit plugins, rotate key passwords.
• Yearly: full audit, reconsider who has access and why.

One last thought to take with you. Security isn't a state you reach and forget; it's a habit, like locking the office door. Nobody can guarantee absolute protection, and anyone promising it is misleading you. But the difference between a site where this list is done and a site where none of it is done is the difference between "someone tried and got nowhere" and "we're in week three of recovering our data".

FAQ