Is your website secure? Most hacks are just attack surface you were built with

How websites actually get hacked

The mental image of a hacker personally targeting your site is almost always wrong. The overwhelming majority of compromises are automated: bots continuously scan huge ranges of the web for sites running software with a known, published vulnerability, and exploit whatever they find, which means your site doesn’t need to be famous or valuable to be hit — it only needs to be vulnerable (Optuno, 2026). Attackers count on small businesses having weaker defences and slower patching, which makes them attractive targets rather than ones beneath notice.

And the software those bots probe is, more often than not, a plugin. On WordPress — which runs around 40% of the web and is therefore the most-targeted platform — an estimated 91 to 96% of vulnerabilities are found in third-party plugins, with only a handful ever appearing in the core itself, and roughly 92% of successful breaches originate in plugins and themes rather than the base software (Colorlib, 2026; SBCSG, 2026). The scale is real: more than 11,000 vulnerabilities were disclosed across the ecosystem in 2025, up 42% year over year, exploits routinely launch within five hours of disclosure, and nearly half of vulnerabilities have no developer patch available when they’re made public (Colorlib, 2026). A concrete 2026 case makes it vivid: a critical flaw in a popular contact-form plugin used on around 50,000 sites let anyone on the internet upload a malicious file with no login at all, scored 9.8 out of 10 for severity (SBCSG, 2026). The base platform can be flawless; the attack surface is everything bolted onto it.

The static-site advantage: a near-zero attack surface

This is where how a site is built decides how safe it is. A static site — pages rendered ahead of time and served as plain files — runs no PHP, queries no database and executes no plugins when a visitor loads a page, and that single architectural fact removes whole categories of attack at once (Universal Cloud, 2026). SQL injection, the classic technique of slipping malicious commands through a form into a database, is simply impossible when there is no database to inject into. Plugin exploits can’t happen because no plugins are running. There’s no PHP on the server to trick into executing a backdoor, and no wp-admin login page sitting on the public internet for bots to brute-force. The public attack surface drops close to zero, not because it’s been carefully defended but because it was never built (UnfoldCMS, 2026).

The delivery method adds another layer. Static sites are typically served from a CDN’s edge network, which spreads the site across many locations and can absorb the flood of a DDoS attack that would overwhelm a single origin server (Universal Cloud, 2026). This is the security reading of the same architecture that our pillar on owning your website recommends for control and portability: a site with fewer moving parts isn’t just easier to own and faster to load, it’s dramatically harder to compromise, because most of the doors an attacker would try simply don’t exist.

The free layer almost no one ships: security headers

On top of a small attack surface sits a layer of protection that costs nothing and that most sites skip anyway. Security headers are instructions your server sends to a visitor’s browser about how to protect that visitor, and the key ones each close off a class of attack: Content-Security-Policy limits which scripts are allowed to run and mitigates cross-site scripting, Strict-Transport-Security forces encrypted HTTPS and blocks downgrade attacks, X-Frame-Options prevents clickjacking by stopping your page being framed on a malicious site, and X-Content-Type-Options stops browsers from MIME-sniffing their way into an exploit (WP Poland, 2026).

The striking part is how rarely they’re used: an estimated 93% of sites are missing one or more modern security headers, running on defaults that haven’t changed since the middle of the last decade (GuardingWP, 2026). These headers don’t patch a vulnerability — they harden how the browser behaves — and they ship as a single block of configuration, which makes adding them one of the highest-value, lowest-effort moves in web security (GuardingWP, 2026). One coordination point matters, and it connects to the rest of our work: a restrictive Content-Security-Policy has to be written so it doesn’t block the inline scripts some assistive technology relies on, so security headers and accessibility need to be set up together rather than in isolation (Xictron, 2026).

Static isn’t a magic shield — the honest part

Reducing the attack surface is not the same as eliminating it, and it would be dishonest to imply a static site can’t be harmed. Several real surfaces remain. Contact forms and any interactive feature still process input, and when they run through serverless functions or third-party services those need validation and rate-limiting like anything else. Third-party scripts and embeds you add to the page carry whatever risk their providers carry. The build pipeline is a genuine target — the packages your site is compiled from can be compromised upstream, the same supply-chain risk that has hit even official plugin repositories (UnfoldCMS, 2026). And your domain and DNS remain attackable regardless of how the site is built, whether through phishing that impersonates your address or hijacking that redirects it.

The honest framing is that a static architecture makes the common, automated attacks mostly inapplicable while leaving a smaller set of surfaces that still need deliberate care — which is a far better position than a large surface you must constantly defend, but not invulnerability. Modern static sites also keep their dynamic features precisely by isolating them: forms, search, authentication and even commerce run through separate specialised services rather than one monolithic system, so a problem in one is contained instead of handing over the whole site (Universal Cloud, 2026). Smaller surface, handled honestly, beats big surface defended heroically.

Is WordPress the problem? Fairly, and with caveats

It would be unfair to leave this as “WordPress is insecure,” because it isn’t quite that. WordPress core is reasonably secure — only a handful of low-priority core vulnerabilities appeared in 2025 — and a WordPress site can be run safely with few plugins, active monitoring, a web application firewall, managed hosting and someone who can read the plugin code it depends on (UnfoldCMS, 2026). The catch is that all of that is real, ongoing cost and expertise, and the economics only make sense for organisations with dedicated development resource. Much of WordPress’s alarming hack volume is also a function of its enormous install base — a tiny percentage of hundreds of millions of sites is still millions of sites — and a large share of real compromises trace back to weak or reused admin passwords rather than exotic exploits (Colorlib, 2026).

So the fair statement is narrower and more useful: for a site whose job is to inform, persuade and convert — a marketing site, a blog, a brochure with contact forms — a database-backed, plugin-driven platform is a large attack surface you have to manage indefinitely, and a static architecture removes that surface rather than managing it. This is the security dimension of the platform choice our pillar on builders and the site you own lays out: the right tool depends on the job, and for most business sites the job doesn’t require the surface. Where a project genuinely needs a database-backed CMS, a headless setup keeps the editing backend behind authentication while serving the public a static front-end — most of the security benefit without giving up the workflow.

Why our sites are secure by construction — and a hack is a privacy event

Stated plainly as our position: the sites we build are secure by construction, and we ship the free layer by default. Because they’re static, they carry the near-zero public attack surface described above; because we configure them properly, they ship with the security headers that 93% of sites omit; and because we run our own reliable infrastructure rather than reselling a plugin-heavy platform, there’s no security-plugin subscription we need to sell you to paper over a surface we could have avoided. We still handle the surfaces that remain — validating what forms accept, serving over a CDN, verifying the host, and keeping the build pipeline clean — because honesty about the residual risk means addressing it, not waving it away.

The gate here is the same two-sided one as everywhere: a static site is much safer, not invincible, and we’ll tell you where its real edges are rather than sell it as a force field. And one connection deserves emphasis, because it ties this guide to the rest of our work: a hacked website is almost always a data breach, and if the data lost includes customers’ personal information, that breach carries obligations and penalties under privacy laws like the GDPR and CCPA, not merely cleanup costs. Security and privacy turn out to be one discipline seen twice — a site that runs little and collects little is both harder to breach and less damaging when breached, because there’s less to attack and less to lose.

The smallest attack surface is the one you never built

Step back and website security resolves into the same principle as speed, privacy and sustainability before it: the danger is excess, and the defence is doing less. A site is vulnerable for the same reason it’s slow and leaks data — because it runs more code, more plugins and more third-party services than it needs, and every one of those is a door. Remove them and the doors close together; a static site with a tiny surface, security headers shipped by default, and no database to breach is the security expression of an architecture built to do less.

So the useful way to think about your website’s security isn’t to shop for another plugin or monitoring subscription to defend a sprawling surface, but to shrink the surface itself: prefer an architecture with no database and no plugin runtime, ship the free security headers, isolate the few dynamic features you truly need, and treat your data footprint as part of your attack footprint. Do that and security stops being an endless defensive chore bolted onto a fragile site and becomes what it should be — a quiet property of a site built to do less, the same “do it right once” logic that runs through our pillar on owning your website and everything else we make. Fast, private, green and secure turn out to be four readings of the same decision.