A small site seems like a dull target: who needs a company card site or a landing page? But most hacks are not aimed at anyone in particular. Bots go through site after site looking for old plugins, weak passwords, and open admin panels. Your site lands on that list simply because it is on the internet.
The good news is that simple, inexpensive things protect against mass attacks. Below is what to do at launch and keep checking afterwards.
Passwords and two-factor login
Start with the accounts that can be used to take the whole site: the domain registrar, hosting, email, the site admin, and the Telegram bot account. Each needs its own long password and two-factor login switched on wherever it is offered.
Passwords are easiest to keep in a password manager, not in phone notes or a chat with the developer. If a password was ever sent in a messenger, it is better to change it.
Personal accounts instead of shared ones
One admin login for everybody is convenient until someone leaves the company or the work with a contractor ends. Then nobody knows who else has the password. It is better when each person has their own account with only the rights they need.
- The owner has full access to everything
- The developer gets separate access that can be closed after the work
- An employee who posts news cannot change settings or install plugins
- When a person leaves, their access is switched off the same day
Updates and the extras
Outdated CMS versions and plugins remain the most common way in. Updates come out partly because a hole was found in the old version. Update on a schedule, with a backup beforehand and a site check afterwards.
Better still is having nothing extra at all. Every plugin, theme, or widget nobody uses is still code on the server that also needs updating. Delete what you do not use rather than just switching it off.
Forms and file uploads
Forms accept data from anyone, so the server must check everything that comes in. If a form lets people upload a file, the file types and size should be limited, and files stored so they cannot be run as a program. This is the developer’s job, but it is worth your asking about it.
Keys and secrets
Database passwords, payment service tokens, and the bot token should not sit in the code or in a public repository. They belong in the server settings. If a token did end up somewhere public, reissue it right away rather than just deleting it from the file.
If the site does get hacked
- Change the passwords for hosting, the admin panel, email, and the database
- Restore the site from a clean backup rather than cleaning the infected copy by hand
- Update everything that is out of date and find how the attacker got in
- Check webmaster tools for warnings and request a review of the site
All of this is much easier when backups exist and a restore has already been tested. So the plan for a hack starts long before the hack itself.
Which of these usually belongs to regular work is described in the note on support after launch, and which access must stay with you in the note on domain, hosting, and access. If you want us to check your site, use the contact form.