Security

Website security: the basic minimum

Websites aren't hacked individually but en masse and automatically. The basic set of measures: HTTPS, updates, access, backups, form protection and what to do after a breach.

Conversations about website security often end with "nobody would bother hacking us". There's a hidden assumption in that phrase: that a hack is a targeted action someone decided to take against you specifically. In practice, the overwhelming majority of hacks work differently, and that changes the whole logic of protection.

Why "nobody would bother hacking us" is the wrong premise

Most attacks are carried out by programs that continuously scan addresses on the internet and check them for known weaknesses. Such a scanner doesn't care who you are: it knows neither your turnover nor your industry. It sees a platform version with a published vulnerability or an admin panel with a weak password.

The motivation isn't directly about you either. A hacked site is needed to:

  • host other people's pages and links — someone profits, while your domain's rankings and reputation fall;
  • send spam from your server, after which email services start blocking mail from your address;
  • redirect visitors to unrelated sites, usually only on mobile devices, so the owner notices later;
  • intercept form data — contact details and payment information;
  • encrypt data and demand a ransom;
  • use your server as part of the infrastructure for attacks on others.

None of these scenarios requires you to be a prominent company. It's enough for the site to be reachable from the internet.

A hack on a small website isn't an event but background noise. The question isn't whether someone will try, but whether they'll find something that works.

The basic minimum

HTTPS

A secure connection isn't optional today. Without it, form data travels over the network in plain text, browsers show warnings, and some features simply don't work.

Check three things: the certificate is valid and renews automatically; the non-HTTPS address redirects to the secure one; pages have no content loaded over the insecure protocol — otherwise the browser complains about mixed content.

Updates

The most effective measure of all. The vast majority of mass hacks use vulnerabilities for which an update has already been released — it just wasn't installed.

Everything needs updating: the platform itself, installed extensions and themes, server software, libraries in the application code. Separately — remove what you don't use: an inactive extension with a vulnerability stays on disk and stays vulnerable.

To keep updates from breaking the site, you need a process: a staging copy where changes are tested, and the ability to roll back.

Access control

A typical picture in a company: one admin login known to five people, including an employee who left a year ago and an outside contractor.

What to do instead:

  1. Each person has their own account — so you can see who did what.
  2. Minimum rights: a content editor doesn't need access to settings and code.
  3. Two-factor authentication for everyone with admin access, and always for the domain, hosting and email.
  4. Unique long passwords stored in a password manager, not in chats or a shared file.
  5. Accounts of departing employees and contractors who have finished their work are disabled the same day.
  6. A periodic review of the list: who has access at all, and why.

A separate note on the domain and hosting. If an outsider controls the domain, any measures on the site itself are secondary — the domain can simply be taken.

Backups and testing restoration

Backups are the only measure that works after everything else has failed. The requirements are simple: made automatically on a schedule; include both files and the database; stored separately from the server itself; kept in several generations.

The last point matters more than it seems. A hack isn't discovered immediately, and the single most recent backup may already contain a backdoor. Several generations let you roll back to a state before the infection.

And the main point: a backup needs to be restored at least once. Testing restoration answers questions that would otherwise come up at the worst moment: how long it takes, who knows how to do it, whether everything actually made it into the backup. A backup that has never been restored from isn't protection.

Form protection

Any open form starts receiving automated junk after a while. The problem isn't just inconvenience: real requests get lost in the flood, and mail from your address may end up caught by filters.

Working measures: server-side validation, not just in the browser; limiting the submission rate from a single source; a modern bot check that doesn't make people solve picture puzzles. Separately, check that form data is handled correctly: content coming from a visitor must not be inserted into an email, the database or a page as is.

Monitoring

The longer a hack goes unnoticed, the more expensive the consequences. The minimum: site availability monitoring, notifications about file changes, regular review of admin login logs, connected webmaster tools — search engines often report an infection before you notice it yourself.

We usually handle these tasks together with support; the dedicated area is described in the security section.

What to do if you're hacked

Order matters: the wrong sequence destroys evidence and leads to reinfection.

  1. Don't delete anything straight away. First take a copy of the current state — files, database, logs. You'll need it to understand how they got in.
  2. Restrict access. Take the site down or disable it if it's harming visitors: serving redirects or files.
  3. Change all passwords — admin panel, database, hosting, FTP, email, domain. End active sessions.
  4. Find the entry point. Through logs and file modification dates. Without this step, restoration achieves nothing: a day later the infection will come back the same way.
  5. Restore from a known-clean backup — not the most recent one, but one older than the moment of infection.
  6. Close the vulnerability: update the platform and components, remove what's unnecessary, fix the settings.
  7. Check that no backdoors remain — extra admin accounts, unfamiliar scheduled tasks, suspicious files, modified system files.
  8. Get sanctions lifted. If the site is flagged as infected, request a review in the webmaster tools.
  9. Assess what leaked. If clients' personal data was affected, you have obligations beyond the technical ones.

The basic checklist

  • HTTPS works, renews automatically, and the insecure address redirects.
  • The platform, extensions and libraries are up to date; anything unused is removed.
  • Everyone has their own account with the minimum necessary rights.
  • Two-factor authentication on the domain, hosting, email and admin panel.
  • Passwords are unique and stored in a password manager.
  • Backups are made automatically, stored separately and in several generations.
  • Restoring from a backup has been tested in practice at least once.
  • Forms are protected against automated submissions, and data is validated on the server.
  • Alerts for site downtime are set up, and webmaster tools are connected.
  • It's written down who is responsible for responding and what they do first in an incident.

None of these points requires special conditions or a big budget. They require someone to be responsible for them. If there's no such person in the company, that's the first thing to sort out — you can discuss it via the contact form.