Most small-business owners think of their website as a brochure, so website security sounds like someone else's problem, a thing for banks and big companies. It isn't. A website is a computer on the internet that anyone in the world can knock on, and the people doing the knocking are almost never people. They're automated programs that scan millions of sites a day looking for the same handful of weak spots, and they don't care whether you're a bank or a bakery.
Over the past month we ran a security check on 54 local business websites here on the Grand Strand, the same first-pass check we run before we take a site on. We only ever looked at what's public: the page itself, the public records that come with any domain, and the version numbers the site announces to anyone who asks. Nothing was logged into, nothing was tested against the site, nothing was touched. Here's the pattern we kept finding.
One in five published their own admin usernames
A website built on WordPress can be asked, in a plain web address, to list the accounts that can log in and edit it. On a site that's set up right, that question gets a polite no. On 11 of the 54 sites we checked, it answered, handing over the login names of the owner and staff to anyone who asked.
A username on its own isn't a break-in. But a login page needs two things, a name and a password, and this gives away the first one for free. The automated programs that hammer login pages all day now only have to guess half of it. Pair that with a login page that doesn't lock anyone out after a hundred wrong tries, which most of these had, and you've left the back door not just unlocked but labeled.
Nearly one in five ran software with known holes
WordPress sites run on add-ons, the plugins that build the pages and the forms. Each one gets security fixes over time, and each one announces its exact version in the page's code. We read those versions and checked them against the public vulnerability databases, the same lists the attackers use to decide what to try.
Ten of the 54 sites were running add-ons with known, published security holes that had already been fixed in a later version the site hadn't installed. On one, a single add-on accounted for a flaw rated 9 out of 10, the kind that lets someone with no login run their own code on the server. These aren't theoretical. When a hole like that is published, mass scanning for it starts within days, because the people running the scans read the same list we do.
Anyone could send email in their name
Your domain carries a short public record, called DMARC, that tells the world's mail systems what to do with a message that claims to be from you but isn't. Set to "reject," a forged message bounces. Set to "none," or missing entirely, it sails through to the inbox looking exactly like you.
Several of the sites we checked had it set to "none" or didn't have it at all. For a business that emails customers about money, a real estate team, a contractor sending invoices, that's the gap a scammer uses to send a fake "updated wire instructions" email that your own customer has no way to tell from the real thing.
The privacy page that wasn't true
This one isn't a break-in, it's a liability. 14 of the 54 sites had a privacy policy that didn't match what the site actually did: a "we don't share your data" promise on a page that loaded a dozen trackers before anyone clicked anything, a "Reject All" cookie button that rejected nothing, a contact address at a domain that no longer existed so every privacy request bounced. A few were copied word for word from another company's policy, name still in it.
Website privacy law has teeth now, and it reaches small businesses that take information from visitors in states like California. A policy that promises one thing while the site does another is worse than no policy, because it's a written record of the gap.
Why a small site gets attacked at all
Owners assume nobody would bother. Here's the part that changes the math: nobody is bothering, in the sense of a person choosing you. The attacks are automated and indiscriminate. A program sweeps the whole internet, your site answers, it tries the known holes, and if one works it moves in, all without a human ever reading your name.
And when it works, it's usually quiet. Not a defaced home page, but hidden spam pages Google starts blaming you for, a redirect that only fires for visitors coming from a search, or the contact-form entries skimmed on their way in. Most owners find out weeks later, when Google puts "This site may be hacked" under their listing or a browser throws up a red warning page in front of their customers. By then the cleanup costs far more than the fix would have.
Check your own site
- Run the free checkType your address into our website check. It reads the public version numbers, the email records and the privacy setup the same way an attacker's scanner would, and tells you in plain words what's exposed.
- Ask who's updating itIf your site runs on WordPress, someone has to install the security fixes as they come out. Ask whoever built or manages it how often that happens. "When something breaks" is not an answer; the fixes have to go on before anything breaks.
- Turn on two-step loginEvery account that can edit the site should need a second step to log in, a code from a phone, not just a password. It's the single change that stops the most attacks.
- Fix the email recordAsk whoever manages your domain to set DMARC to "reject." It stops people forging email in your name and costs nothing.
How we checked, for the technically minded
So the numbers above aren't a guess, here's exactly what the check reads, all of it public and none of it a test run against anyone's server. If you manage sites yourself, you can run every one of these on your own.
- Software versions. A WordPress page announces the exact version of each plugin and theme in its own code, in the version tag on every stylesheet and script and in the generator tag. We read those and matched them, version by version, against the public vulnerability databases, Patchstack and the WordPress advisory feeds, then cross-checked the serious ones against CISA's Known Exploited Vulnerabilities catalog, the U.S. government's list of flaws confirmed to be under active attack.
- Exposed accounts. WordPress has a built-in address that returns the login names of a site's authors and admins unless it's been locked down. We asked each site that question and recorded whether it answered.
- Email spoofing. We pulled each domain's public SPF and DMARC records, the same DNS lookup any mail server does, and read the DMARC policy: reject, quarantine, or none. None, or no record at all, is what lets someone forge mail in your name.
- Cookie and privacy claims. We loaded each site in a fresh browser with no history, recorded every outside company it contacted and every cookie it set before anyone clicked anything, then pressed Reject All and reloaded to see whether the trackers actually stopped. We compared that to what the written privacy policy promised.
- The infrastructure. The server's own response reveals its PHP version and whether the standard browser protections are switched on. We noted versions that have passed their security end-of-life and protections that were missing.
If it's already happened
If your site is already showing a warning in Google, redirecting people somewhere strange, or you've gotten the email that something's wrong, don't wait and don't start deleting things, which can destroy the evidence of how they got in. We handle this: a full backup first so nothing is lost, a check for how they got in and what they touched, the site cleaned and the hole closed, and the request to Google to lift the warning once it's genuinely safe. Then a written account of what happened and what we changed.
Security is where this work started for our founder, as a teenager, and it's built into everything we make now: every site we build is locked down from day one, kept patched, and watched. If you want a second set of eyes on yours, the free check is the place to start, or just reach out and we'll take a look.
Written by Nikita Huttenlocher, founder and lead engineer at Huttenlocher Technologies, a web design and software company in Myrtle Beach, South Carolina.