Keeping a public website out of the incident queue

The public website occupies an unusual position in most organizations. It is business-critical in the sense that its absence is embarrassing and visible, and non-critical in the sense that nothing internal stops working if it goes down. It is often the only system with no named technical owner, because it was built by an agency, handed over, and has been quietly running ever since.

It is also, by construction, the most exposed system you own. It must be reachable by anyone, it runs a content management system shared with millions of other sites, and it is continuously scanned by automation that is not looking for you specifically.

We take on a lot of sites in exactly this state. The pattern is consistent enough to be worth writing down.

How a marketing site actually gets compromised

Rarely through a clever attack on your organization. Almost always through one of four routes.

A vulnerable plugin or theme. The core platform is generally well-maintained and patched quickly. The ecosystem around it is uneven — plugins abandoned by their authors, themes with bundled libraries frozen at the version shipped in 2019, extensions installed once for a campaign and never removed. This is the majority of what we see.

A weak or reused administrative credential. Public login pages are enumerated and attacked continuously. An administrator account with a memorable password and no second factor will eventually be found.

Stale supporting infrastructure. An outdated PHP version, a database with an exposed port, a control panel with a default configuration, a staging copy of the site at a guessable subdomain running last year's code with a copy of production data.

Supply chain, via the agency. Shared credentials across many client sites, a compromised developer workstation, or an FTP account created for a contractor in 2021 that still works.

Why the consequence is bigger than the site

If the site were isolated, compromise would be an inconvenience. It usually is not.

The most common real damage is reputational and operational rather than data loss. Compromised sites are used to serve malware to visitors, to host phishing pages under your domain, and to inject content for search manipulation. The first you hear of it is often a browser warning on your own homepage, a customer's email filter blocking your domain, or a sharp fall in search traffic that takes months to recover.

Where the site is not isolated the damage is worse. A site sharing a server with internal applications, or holding database credentials that also work elsewhere, or running on infrastructure inside your network, turns a low-value target into a foothold.

The single most valuable architectural decision is therefore isolation: the public site runs somewhere that touches nothing else, with credentials that work nowhere else.

What a maintained site actually looks like

The operational baseline is not complicated. It is just unowned.

• Core, plugins and themes updated on a defined cadence, with a staging copy to catch breakage before production sees it.
• Every plugin and theme inventoried, with the ones nobody can justify removed rather than deactivated. Deactivated code is still present and still exploitable in some configurations.
• Administrative accounts audited: no shared logins, no agency accounts left over from finished projects, MFA on everyone who can edit.
• The platform beneath it current — language runtime, database, web server — which is where hosting choice matters, because cheap shared hosting frequently pins you to an old runtime.
• Backups that are offsite, versioned, and restore-tested, so that recovery is a decision rather than a project.
• A web application firewall in front, which does not replace patching but buys time between disclosure and your maintenance window.
• Monitoring that checks availability, certificate expiry, and file integrity, so that a defacement is detected by a system rather than by a customer.

Cleaning up is not the same as recovering

When a site is confirmed compromised, the instinct is to remove the malicious files and move on. We advise against it, and it is worth being explicit about why.

An attacker who achieved code execution had the opportunity to establish persistence in several places: additional administrative users, modified core files, scheduled tasks, injected database content, and web shells in directories nobody inspects. Removing what a scanner found removes what a scanner found. It does not establish that nothing else remains.

The reliable approach is to rebuild: fresh platform installation, content restored from a backup predating the compromise or from a reviewed export, plugins reinstalled from source rather than copied, every credential rotated including database and hosting, and the entry route identified and closed before the site goes back up. Identifying the route matters most — a rebuild that restores the same vulnerable plugin is a scheduled repeat.

Where we land on this

A public website is a system, not a document. It runs code, it accepts connections from the entire internet, and it decays without maintenance in a way that a printed brochure does not.

The organizations that never have a problem with theirs are not doing anything sophisticated. They have simply assigned it an owner, put it on a patching cadence, isolated it from everything that matters, and arranged for a machine to tell them when it stops working. That is a modest standing cost, and it compares favourably with the alternative — which, in our experience, is a rebuild under time pressure while the marketing team asks hourly when the site will be back.