How to protect a website from hacking: the basics - Zephyra Studio

An attack on a small website is rarely personal and rarely sophisticated. Automated scanners sweep the internet looking for known weaknesses: a plugin left unpatched, a system version without a fix, a password that a dictionary breaks. Protection therefore does not start with a firewall but with three things that are also the cheapest: regular updates, unique passwords with two-factor authentication, and a backup that is tested from time to time. In that order they cover most of the real risk, and what remains are measures that limit the damage if a breach happens anyway. This article deliberately describes defence only, never attack techniques.

The biggest risk is not the attack but the weakness that stays open

When a vulnerability in a plugin or platform is published, it becomes public the same day in databases read by researchers and attackers alike. From that moment automated tools scan addresses looking for sites that have not applied the fix. There is no selection of targets by size or industry, because the scanner does not know whose site it is.

The conclusion is that time is the main risk. A site updated in small steps rarely has a publicly known weakness open, while a site touched once a year spends months in a state that is publicly known to be vulnerable.

The same pattern applies to access. A shared admin account whose password has not changed in years, a former contractor who kept access, and one password reused across other services are all ways in that involve no technical attack at all.

Three measures that cover most of the risk

If nothing else from this article gets done, these three measurably reduce the risk. None of them needs a budget, only consistency.

• Update the platform, plugins and themes, applying security patches within days rather than months
• A unique and long password for every account, stored in a password manager, never reused on other services
• Two-factor authentication on administrative accounts and on the mailbox used to reset passwords
• A separate account per person, with only the permissions that person needs to do the job
• An automatic backup kept outside the server the site runs on, tested by restoring it now and then
• Deleting plugins and themes that are not used, because they still sit on the server and can carry a flaw

How to keep protection from getting in the way

Any protective measure can also be excessive. A login limit set too tightly locks out staff who mistyped a password three times, while a rule blocking everything except known addresses can cut off calls from a payment service.

That is why tightening happens gradually and with a test after each change. After every new rule, check the admin login, form submission, arrival of enquiry notifications and, on stores, a full purchase from cart to confirmation.

The second common mistake is leaving helper addresses and files on the server. A test version of the site, a configuration file and a database copy left behind are often more exposed than the site itself, while serving nobody.

Protection does not rely on something being hard to guess. Hiding the admin address slows automated attempts, but it does not replace a strong password, two-factor authentication and updates, because those three are checked in every breach.

Finally, the state of protection is checked from outside as well as from inside. Our free website security check shows whether the domain appears on the unsafe sites list and whether public data reveals an outdated platform version, because that is what a visitor sees before opening a page.

Measures that limit the damage when something does happen

Assuming a breach can happen despite the measures, the question becomes how quickly it is noticed and how far the damage spreads. The first measure is monitoring: checking that the site is reachable and that files have not changed without your knowledge. Without it, a breach is usually discovered only when a customer reports a browser warning.

The second group limits movement through the system. File editing disabled in the admin area, a cap on login attempts, blocked access to sensitive files, and hosting that keeps the site isolated all shorten the distance from one weakness to the whole site.

The third group concerns data. If the site stores customer details or enquiries, they should not sit on the server longer than needed, nor in any form other than what the work requires. After a breach the damage is measured in data, not in how the site looks.

What to do in the first hour after a breach

The first hour decides how much work follows, so it helps to have the list ready in advance, before anyone panics. The goal is not to fix everything at once but to stop the spread and preserve evidence.

• Change passwords on every account connected to the site, starting with the mailbox used to reset access
• Review the user list, remove accounts you do not recognise, and rotate access keys
• Stop public access to the site until the extent is known, if it has been serving someone else's content
• Restore a backup from before the breach, from a verified source, and update it immediately afterwards
• Report the problem to the host, which sees server-level logs you cannot see
• Check the security warnings in Search Console and remove injected pages and redirects
• Never pay a ransom demand, because it does not reliably return access and offers no guarantee

Source

Key takeaways

• Most of the risk comes from known weaknesses left open for a long time, not from advanced attacks.
• Updating, unique passwords with two-factor authentication, and a tested backup cover most of the real risk.
• Monitoring cuts the gap between a breach and a response from weeks to hours.
• Least privilege per person limits the damage a single compromised account can do.
• The first hour after a breach is for stopping the spread and preserving evidence, not for fixing everything at once.

Conclusion

Protection is not installed once but maintained, and most of the work is dull: updates, passwords, backups and checking that everything is in place. If you do not know what state your site is in, our free website security check shows whether you appear on the unsafe sites list and whether public data reveals an outdated platform version. We covered the typical mistakes in more detail in our article on the most common website security mistakes, and cleaning up after an incident and hardening the site for good is covered by our website security service.