Blog

Nobody chose your business

Website scanning is automated and impersonal, which is exactly why the list of things that stop it is short, boring and finite.

Nobody chose your business. That is the part that is easy to get wrong about website security.

An hour of a small site's request log: five automated attempts at common addresses, and one actual visitor. An example, not anybody's log.

You may not know what your website is built on. Mostly it does not matter. Wix, Squarespace, GoDaddy's builder and Shopify are hosted builders. On one of those, the accounts, the domain, the two-factor authentication and the free checks all apply. Where a step is only for WordPress, it says so.

What is actually happening

The scanning is automated. Software works through every address it can find, tries a list of holes that are already public, and moves on. It does not care how small you are, or that the bookings come in by phone, or that the site is five pages long. You are not a target. You are a row in a list.

That is better news than it sounds, because it changes what the fixes look like. You are not defending against somebody who is thinking about you. You are closing doors that a machine will try, fail, and move past. The fixes are boring, there is a small number of them, and they end.

You can watch this happening, if your hosting has a control panel. Open your website's access log. cPanel-based hosting shows one under Raw Access or Visitors. Some platforms do not give you a log at all, and if yours does not, go straight to the list below. Scroll through a minute of it. The lines worth noticing are requests for pages that do not exist, login screens for software that was never installed, and file names that were never there. If you find none, that is a fine result too.

Five things, in this order

Set aside an afternoon, or take one step a day between clients. None of this needs a specialist.

1. Know what your site runs on, and who updates it. The holes being tried are already public. That usually means the fix is public too, and older than the attempt. On a hosted builder, the host updates the software and there is nothing for you to install. On WordPress, the Updates screen tells you where you stand. If somebody else built the site and you have no login, email them and ask when it was last updated. "I do not know" is a useful answer.

2. Remove what you are not using. Every plugin, theme and connected app is more code sitting on your site, including the ones that were tried once and left in place. On a hosted builder, remove the apps you no longer use. On WordPress, deactivating a plugin leaves its files where they were, so delete the ones you will not use again. Keep one default theme installed. WordPress falls back to it if the active theme breaks.

3. Two-factor on three accounts: the domain, the hosting, the email. On a hosted builder, the hosting account is the builder login. The domain registrar is the account that is easiest to forget. Whoever controls your domain can point it anywhere, and can often reset other passwords through the email address attached to it. While you are in the registrar panel, check the expiry date on the name. Check the contact email on the record. A .com.au name is a licence, with a renewal date and a contact. If that contact is somebody who has left the business, change it today.

4. Know who still has access. Write the list on paper: the website logins, the hosting or builder account, the domain registrar, the shared inbox, your Google Business Profile managers, the booking system, the social accounts. A receptionist who left last year. A developer from three years ago. A friend who helped once and meant well. For each name, the question is not whether you trust them. It is whether you would notice.

Access is not the same as ownership. The name the domain licence is held in is a public record, and checking that record is the first thing to do before agreeing to a rebuild.

5. Have a backup you have actually restored. A backup you have never restored is a file, not a backup. Set aside a quiet morning for the test, and there is a separate post on how to run it. On a hosted builder, keep your own copy of the page text, the photos and the price list.

What is not worth worrying about

The log noise itself is not an incident. Requests for a WordPress login on a site with no WordPress are a machine knocking on a door that is not there. There is nothing to do about them, and blocking each address by hand never ends, because the list refills.

A letter grade from a free header-scanning site is not an emergency. Missing security headers are worth adding the next time somebody is in the code. They are not a reason to ring anyone on a Sunday. On a hosted builder, your host sets those headers and there is nothing for you to do.

Contact form spam is annoying, not a break-in. It mostly means the form works.

A cold email telling you a vulnerability was found on your site is a sales message until proven otherwise. Do not click anything in it. Run the free checks below yourself instead. That includes ours. Anything we write to a company names what we saw in a browser, on a stated date, and nothing else.

The exception worth taking seriously is a self-hosted one: software that no longer receives updates at all. If the version you are on stopped being supported, no amount of care fixes that, and it belongs on the list of things to plan.

Free checks you can run today

All four work whatever your site is built on.

Google Search Console, under Security and Manual Actions. You verify the site once before Google will show you anything. Verification is free and it is a one-off step. If Google has detected something, this is where it says so, and it names the pages. Empty is what you want.

Google's Safe Browsing site status, at transparencyreport.google.com/safe-browsing/search. Type your domain. It tells you whether Google is currently warning visitors away from you. If traffic has dropped suddenly, a warning here would explain it.

MXToolbox, at mxtoolbox.com. Run the blacklist check and the SPF record lookup on your domain. Read a listing before you act on it. Many listings are against a shared address belonging to your mail provider rather than against you. A listing on a list you have never heard of is not the same as being blocked by Gmail or Outlook. If your own mail is arriving normally, note it and move on.

Have I Been Pwned, at haveibeenpwned.com. Enter each email address that can log in to anything on the list you wrote in step four. A result here is not proof of a problem on your site. It is a reason to change that password and turn on two-factor, which was step three anyway.

Where to start

Do step three first. Two-factor on the domain, the hosting and the email is quick, and it can be done in one sitting. It also protects the accounts the other four steps depend on. Then write the access list. That is the order we would use on a site we had never seen, because a website can be rebuilt and a domain sitting in somebody else's account cannot.

If you would rather give the afternoon to someone else, that is the kind of work we take on. Either way, the list above is the whole list, and it is finished when it is finished.

Questions people ask

Is a small business website actually a target for hackers?
Most attempts against a small site are not aimed at that business specifically. Automated software works through every address it can find, tries holes that are already public, and moves on. It does not know what the business sells or how few visitors the site gets. That is why the practical fixes are broadly the same for every small site.
How can I check for free whether my website has a security problem?
Google Search Console has a Security and Manual Actions section, and it names the affected pages if Google has detected something. You verify the site once before Google will show you anything. Google's Safe Browsing site status page at transparencyreport.google.com/safe-browsing/search shows whether visitors are currently being warned away from your domain. Neither tool can prove a site is clean, but a warning in either one is real and needs attention.
Which accounts should get two-factor authentication first?
The domain registrar, the hosting account, and the email address attached to both. The domain is the one that gets forgotten. Whoever controls it can point the website anywhere, and can often reset other passwords through the email address on the record.
My site is on Wix or Squarespace and I cannot find an access log. Does that matter?
No. Most hosted builders do not give the owner a raw log, and the log is a curiosity rather than a task. Blocking scanning addresses by hand takes a long time and the list never ends. The five steps in this post are written for a hosted site as well as for WordPress.