Serious website incidents usually start in an unremarkable way. An abandoned plugin nobody remembers installing, a password reused from an old forum account, an admin panel reachable from the open internet, a database backup left in a public bucket. Website security improves mostly by removing those openings and keeping them closed, rather than by adding an impressive product on top of them.
Start with the boring controls
- Patch the whole stack on a schedule: framework, dependencies, content management system and server image.
- Turn on multi-factor authentication everywhere, beginning with administrative accounts.
- Apply least privilege by default, and delete accounts belonging to people who have left.
- Remove unused plugins, themes, endpoints and sample applications rather than leaving them disabled.
- Take backups automatically, and restore one into a test environment periodically instead of only on the day it matters.
Those five measures address a large share of realistic risk, and none of them require a specialist permanently on call. Their weakness is that they depend on rhythm, so put them in a calendar with a named owner rather than in an intentions document. A patch applied in the week it is released is worth far more than a policy describing how patches should ideally be handled.
Know your attack surface
Every form, upload field, integration endpoint and administrative route is a place where untrusted input arrives. Client-side code belongs on that list too: third-party scripts, chat widgets, tag managers and analytics snippets run with the same trust as your own JavaScript and can be changed by someone outside your organisation. Every dependency in your build is also part of the surface, which is why keeping that list short and current is a security decision rather than a tidiness one.
Protect people, not only servers
A convincing email to a member of staff often bypasses every technical control you have. Reduce the value of a single compromised account: use a password manager, prefer passkeys or hardware-backed second factors, shorten session lifetimes on administrative tools, and require re-authentication for sensitive changes such as payment details, payout accounts or user permissions. Log administrative actions so that unusual activity is visible while it is still a question rather than an incident.
On the application side, validate and encode input on the server even when the browser already does, parameterise database queries instead of assembling strings, and set a content security policy that limits which origins may execute script. None of these are exotic techniques, and all of them are considerably easier to add while the application is small than after it has grown a dozen integrations.
Detect, then respond
You cannot respond to what you never recorded. Centralise application and access logs, alert on the events that actually matter, rate-limit authentication and public endpoints, and keep a written plan naming who decides, who communicates and how customers will be told. Rehearse that plan once with the people named in it; a plan that has never been read aloud tends to dissolve in the first ten minutes of a real event.
- Contain the incident: revoke credentials and sessions, isolate the affected service, preserve logs before they rotate.
- Establish scope: what was accessed, what changed, and how far back the activity goes.
- Fix the entry point rather than only the symptom, then verify by rebuilding from known-good source.
- Notify anyone affected, including regulators where your obligations require it, in plain language.
- Review afterwards and convert each finding into a permanent control, test or monitoring rule.
Security is a maintenance discipline that occasionally looks like an emergency, not an emergency that occasionally looks like maintenance.
Aim for proportionate and current rather than perfect. A small site that patches promptly, enforces strong authentication, holds tested backups and can explain its access model is in a far stronger position than one defended by an elaborate tool nobody has configured. Security work is never finished, but it can be routine, and routine is what actually holds up over years.
