Security work that assumes somebody is already trying

How websites actually get compromised

The realistic threat to an ordinary business website is not a targeted attack by a determined adversary. It is an automated program working through a list of addresses looking for known vulnerabilities in outdated software, weak or reused passwords, exposed administration areas and misconfigured servers. It never sleeps and it does not care what your business does.

The consequences are rarely dramatic at first. Compromised sites are typically used quietly, to host spam pages that damage your search reputation, to send email that gets your domain blocked, to redirect a portion of your visitors to somewhere unpleasant, or to sit waiting until they can reach something more valuable. Owners frequently discover it weeks later, from a browser warning or a customer complaint.

The defence is mostly discipline rather than cleverness. Keep software patched. Do not expose what does not need exposing. Use strong authentication. Check permissions on the server rather than in the interface. Keep backups that have been tested. Watch the logs. None of it is exciting, and it prevents the overwhelming majority of real incidents.

What a security review covers

We begin with the software layer, checking which versions of frameworks and libraries are in use, whether any have published vulnerabilities, and how updates are currently applied. Out of date dependencies are the single most common finding and the most likely to be exploited.

Then the application itself, examining how authentication works, whether permissions are enforced on the server rather than only hidden in the interface, whether user supplied input is handled safely, whether file uploads are restricted appropriately, how sessions and password resets behave, and whether error messages reveal more than they should.

Then the server, covering exposed services, firewall rules, administration access, login attempt limits, certificate configuration, security headers, log retention and whether backups exist and can actually be restored. Finally we look at the human layer, including shared accounts, departed staff with active access and credentials stored somewhere they should not be.

Recovery when something has already happened

If a site has been compromised, the priority order is containment, understanding, cleaning and prevention. That means restricting access first, then establishing how entry was gained, because restoring a backup without closing the route simply resets the clock until it happens again.

We then rebuild or clean, change every credential that could have been exposed, patch the weakness, and check for anything left behind such as additional accounts, scheduled tasks or modified files. Afterwards you receive a written explanation of what happened, what was done and what has changed to prevent a repeat, in language you can share with anyone who needs to know.

Security as part of building, not an addition

Everything we build includes secure connections, sensible password handling, permission checks enforced on the server, protection against the common web attacks, restricted file uploads, scheduled dependency updates, firewalls, login attempt limits and tested backups. None of it is quoted as an optional extra. Software without those things is not finished, and treating them as negotiable is how suppliers win on price and leave clients exposed.