Most small-site breaches are not targeted attacks; they are automated tools sweeping the internet for known mistakes. Which means basic protection removes most of the risk, and you do not need to be technical — you only need to ask.
The ten questions
- Does the whole site run on HTTPS, with automatic redirects from the unencrypted version?
- Where are passwords stored, and are they hashed with a modern one-way algorithm?
- Is there a limit on failed login attempts before a temporary lockout?
- How is database injection prevented in search fields and forms?
- What stops an executable file being uploaded through the image upload form?
- Are backups automatic, where are they stored, and when was a restore last tested?
- Who holds admin access, and is it revoked when a contract ends?
- Are the libraries current, and who updates them after handover?
- What gets written to the logs on error, and is sensitive data excluded?
- Do detailed error messages appear to visitors on the live site?
One bad sign is enough
If you ever see a detailed error showing a file path or a database table name while browsing the live site, that alone tells you the setup is incomplete. Those messages are a tool for the developer during development and should never reach a visitor.
What your small site does not need
Do not pay for enterprise security products on a brochure site. The basics above, with decent hosting and regular updates, cover practical reality. Overspending on security while the backup has never been restore-tested is priorities upside down.
After handover
Agree in writing who updates libraries and who watches for failures, and how often. A website is not furniture delivered once; it is software running in an environment that keeps changing. Most breaches we are called in to clean up trace back to a library untouched for two years, not to a new vulnerability.