Website security: what to close in advance and what to do in the first hours

You are not attacked for being interesting

The commonest objection runs: who would bother with us, we are a small site. It rests on a wrong picture of what happens.

Nobody selects you personally. Automated sweeps do the work: once details of a vulnerability become public, a blanket check of every site for it begins. Your size is irrelevant to that.

What follows: somebody else's pages placed on your domain to resell links, visitors redirected elsewhere, spam sent from your server. All of it quiet, and you find out late.

Below: how to recognise what happened, what to do in the first hours, and why half of the defence consists of dull things nobody does.

What it looks like when it happens: Outdated plugins and reused passwords are the two…

A break-in almost never looks like a break-in. There is no red banner.

The first sign: an email from your host about excessive load or spam being sent. That is often how owners find out.

The second: a warning beside your site in search results, or in the browser on arrival. By then the problem is already visible to your customers.

The third, the quietest: pages you never made start appearing in search under your domain. That takes a minute to check — search for your own site and look at the list of pages.

And the fourth: the site loads normally from your computer but redirects visitors arriving from phones or from search. That is done deliberately so the owner takes longer to notice.

Where entry usually comes from

Five entrances, and all five close without specialist knowledge.

Outdated plugins and themes. The commonest entrance. An abandoned plugin keeps running and stops receiving fixes, and within a year it is a known hole.

Weak and reused passwords. An admin password matching your email password means a leak in one place opens the other.

One shared account for everybody. When five people use one password, a former employee among them, entry cannot be traced and access cannot be revoked from anyone.

A forgotten staging copy of the site on the same server. Nobody updates it, and it opens the way to the same files and database.

And unrestricted file uploads. A form that accepts any file and drops it into an open folder is an invitation.

Passwords and access

Half of the defence, and it costs nothing.

Every person gets their own account with their own role. There should be no shared passwords in the admin, at the host, or at the domain registrar.

Two-factor sign-in everywhere it exists: email, hosting, registrar, admin. It is the one measure that keeps protecting even after a password leaks.

A password manager instead of a file with a list. That also solves reuse: a distinct password for every service, remembered by nobody because it does not need to be.

And a leavers procedure: the account is disabled the same day rather than deleted — otherwise the change history disappears with it. Shared passwords that person knew get changed.

Updates: Who would bother with us, we are a small site rests on a…

The other half of the defence, and it is dull enough that it does not get done.

Updates are released mostly to close vulnerabilities. Between details of a hole becoming public and the automated sweeps starting, hours usually pass.

People skip them because an update sometimes breaks the site. The logic of if it works, do not touch it holds right up until the first incident.

The correct order removes almost all of the risk: a staging area, the update there, a check of key journeys, then production. Half an hour of work.

And delete what you do not use. A disabled plugin remains code on the server and remains vulnerable too. It is worth going through the list every six months.

Backups are the last line

Everything above reduces the probability. A backup determines what the event costs if it happens anyway.

A copy on the same server as the site is not a backup: when the server is compromised, so is the copy.

Two are needed: one at the provider and one of your own, elsewhere. The second is made automatically and downloaded regularly.

Retention depth matters more than frequency. A break-in is usually not discovered immediately, and a week-old copy may already contain the implant. Keep copies going back at least a month.

And test restoration. A backup never restored does not count as working. Once a quarter, deploy it to a staging area and confirm the site comes up.

The first hours

The order of actions once it has happened. The order matters more than the speed.

First: delete nothing. Take a full copy of the site's current state and of the logs, compromised as they are. Without it you will not learn how entry was gained, and you will close the wrong door.

Second: change passwords — all of them, starting with hosting and the domain registrar rather than only the admin. And revoke active sessions where that is possible.

Third: take the site down behind a maintenance page for the duration. Leaving it up and infected costs more than losing a day of availability.

Fourth: tell your host. They have logs you do not, and they often see the entry point faster.

And fifth, the forgotten one: if customer data was exposed, you acquire notification obligations, and they differ by country. That is a question for a lawyer, and it should be asked on day one rather than at the end of the investigation.

How to recover

The temptation to clean up and move on is strong, and it almost always leads to a repeat.

There is one reliable route: deploy a clean copy made demonstrably before the incident and apply updates. Not cleaning the infected version — there are usually several implants, and you will miss one.

Content added after the backup date is moved across by hand and selectively, not by restoring over the top.

After recovery, rotate every integration key and token: payment provider, mailing service, external services. A changed password with an unchanged access key is the commonest reason for a second entry.

And request re-crawling in the search consoles if foreign pages appeared in results. The same consoles carry a security issues report showing whether the warning has been lifted.

So it does not happen again

A post-incident review that takes an hour and is worth more than the recovery itself.

Answer three questions in writing: how entry was gained, how long it went unnoticed, and what prevented it being noticed sooner.

The third is the valuable one. The answer is usually that nobody was looking. Which means what is needed is not new defence but an alert.

The minimum set of alerts: a load notification from the host, the security issues report in the search console, and a simple check that the home page responds and contains the text it should.

And appoint somebody responsible for updates, with a slot in the calendar. Security is recurring work, not a one-off configuration.

Secure connections

A short section, because this has been settled for a long time.

A certificate belongs on every site, not only those taking payment. Without one the browser shows a warning, and half the visitors leave before finishing reading it.

It is free now and renews automatically almost everywhere. It breaks in exactly one situation — when auto-renewal quietly stopped working.

So set yourself a quarterly reminder to check the expiry. It takes thirty seconds, and the consequence of an expired certificate is a site that looks compromised while being perfectly fine.

And confirm the whole site is served only over the secure address, with the insecure one redirecting. Mixed mode produces warnings on individual pages, and customers are usually the ones who find them.

An hour-long checklist

Ten points that close most of the standard entrances.

Every person has their own account and there are no shared passwords.

Two-factor sign-in is enabled on email, hosting, the registrar and the admin.

Passwords are not reused between services.

All plugins and themes are updated and unused ones are deleted.

Staging copies of the site are removed from the production server.

A backup is held off the provider's server and has been restored at least once.

Backup retention goes back at least a month.

The certificate is valid and renews automatically.

Alerts are configured at the host and in the search console.

And somebody is named as responsible for updates, with a date in the calendar.