Web & Infrastructure

Your internal network has a firewall. Your endpoints have antivirus. Your website is sitting on the open internet with a plugin that hasn’t been updated in eight months.

There’s a disconnect I see consistently when organizations think about security. They invest in protecting the inside — the network, the devices, the email — and treat the website as a communications tool someone else is responsible for. The web team handles it. The agency handles it. It’s fine.

Except it’s not separate from your security posture. It is your security posture’s most exposed edge. It’s public-facing, it runs software with known vulnerabilities, it’s often connected to payment systems or member databases, and in many organizations, nobody owns the security side of it in any meaningful way.

I manage web infrastructure for a large nonprofit with properties serving a global membership. I’ve spent the last year building out WAF coverage, auditing subdomains, chasing down outdated PHP versions on staging servers, and dealing with brute-force login attempts on environments that had no authentication layer at all. This isn’t hypothetical. It’s Tuesday.

WordPress powers somewhere around 43% of the web. It’s also the most actively targeted CMS on the planet — not because it’s inherently insecure, but because the volume of installations running outdated plugins and themes creates an enormous, reliable attack surface that automated scanners probe constantly.

An unpatched plugin vulnerability doesn’t wait for someone to notice. Bots are scanning for it within hours of a CVE being published. By the time a human reviews the update and decides it’s safe to push to production, the window has already been open long enough for automated exploitation attempts to have run against every site on the internet running that plugin version.

The answer isn’t to panic about updates — it’s to have a defined process, a staging environment to test them, and ideally a Web Application Firewall that provides a layer of protection while that process runs.

Here’s something that comes up in nearly every web infrastructure audit I’ve done: subdomains that nobody remembers setting up, or that were set up for a specific project years ago and never decommissioned. staging.yourdomain.com running an old CMS install. dev.yourdomain.com with default credentials. An old events site on a subdomain that still resolves but is no longer maintained.

Every one of those is an entry point. Attackers don’t care that the subdomain was “just a test environment.” If it’s on your domain, it carries your trust, your certificates, and potentially access to your infrastructure.

Audit your DNS. Know what’s resolving. If you can’t explain why a subdomain exists and who is responsible for keeping it secure, it should be decommissioned or locked down immediately.

A WAF sits between the internet and your web server and inspects traffic before it reaches your application. It blocks common attack patterns — SQL injection, cross-site scripting, malicious bots, brute-force login attempts — and gives you visibility into what’s being thrown at your site on any given day.

For most organizations, this isn’t something you build yourself. Services like Sucuri, Cloudflare, or AWS WAF sit in front of your infrastructure and handle it. The cost is reasonable. The protection is real. And the traffic logs alone are worth it — you’ll see what’s actively probing your site and be able to make informed decisions about your threat posture rather than guessing.

The configuration takes effort to get right — allowlisting legitimate traffic, tuning rules so you’re not blocking your own users — but that’s a one-time investment with ongoing returns. It’s not set-and-forget, but it’s also not a full-time job once it’s dialed in.

The most important question isn’t technical. It’s organizational. When something goes wrong with your website — not if, when — who owns it? Who gets the call? Who has the access, the backups, the credentials, and the understanding of the stack to respond?

If the answer is “our web agency,” that’s a relationship worth examining. Agencies build sites. They are not always equipped or contracted to be your security incident response team. Know what’s in your agreement, know what your agency covers, and make sure someone on the internal side understands the infrastructure well enough to act if the agency is unreachable at 11pm on a Friday.

Your website is not a brochure. It’s infrastructure. Treat it accordingly.

Sources

WordPress Usage Statistics, WordPress.org · Sucuri Website Threat Research Report · OWASP Web Application Attack Reference