How sites actually get hacked
Strip away the drama and most website breaches come through a short list of doors:
- Outdated plugins and themes. A known flaw in one add-on, left un-patched, is the single most common way a site gets compromised. The more plugins you run, the more often this lottery is drawn.
- The database. When pages are assembled live from a database on every request, that database is reachable — and a mistake anywhere in the stack can expose it.
- The admin login. A public
/wp-adminis a permanent target for password-guessing bots, around the clock. - The hosting environment. Server software that's a version or two behind, or a shared host with a noisy neighbor, widens the opening.
Notice the pattern: nearly all of it lives in the machinery that builds the page on demand. Take that machinery off the public path and most of the list disappears with it.
Why static sites are safer by default
A static site is published as finished files. There's no live database sitting behind the page, no plugin executing on each visit, no admin panel exposed on the public domain. An attacker probing your site finds plain HTML and very little to push on.
You can't break into a room that isn't there. The most secure component is the one you removed.
The editing tools still exist — they just live somewhere separate from what the public can reach, and they don't run on every page load. That separation is the whole point: the part of your site the world touches is also the part with the least to exploit.
Why this matters: Security isn't only about the breach itself. It's the cleanup, the downtime, the awkward email to your customers, and the trust you have to rebuild. The cheapest version of all of that is the breach that never had a door to come through.
What still needs attention — on any site
Static or not, a few fundamentals always matter, and we build them in:
- HTTPS everywhere, with certificates that renew themselves so they never lapse.
- Locked-down forms. Contact and signup forms are where real data enters — they need spam protection, validation, and a trusted handler.
- Least-privilege access. Fewer admin accounts, strong authentication, and access that's removed the day someone no longer needs it.
- Vetted third-party scripts. Every analytics tag, chat widget, or embed is code from someone else running on your page. Each one is a small trust decision — and, increasingly, a privacy question too.
- Real backups you've actually tested restoring, not just the ones you assume are running.
The quiet overlap: security and privacy
That last point about third-party scripts is where security blends into privacy. The same tags that widen your attack surface — pixels, trackers, embeds — are also the ones drawing a fast-growing wave of privacy lawsuits over how visitor data is collected. Tightening one tends to tighten the other. We wrote about that wave and how to get ahead of it here.
Where to start
You don't need to rebuild everything tomorrow. Start by knowing what you're exposed to: which plugins are running, what's out of date, what scripts load on your pages, and where your forms send data. That inventory alone usually surfaces the few fixes that matter most.
Want a clear read on where your site stands today? Get in touch and we'll walk through it with you — no scare tactics, just the short list of what's worth doing.