Three doors into a hacked WordPress site

They said your site is a risk. Nobody told you why.

Someone told you the WordPress site is a risk, and nobody explained why. You are between calls, the phone is the whole business, and now you wonder whether the site that rings it is the next one on somebody's list.

In our view, sites like that get hacked because they expose more moving parts than a finished page does. There are plugins that need updates, a database behind the forms, and code that builds each page on each visit. Each part is a door.

The myth says someone was careless

The myth is that a site gets hacked because its owner was careless. We think the design matters more. A site with plugins, a database and code running on each visit gives an attacker three places to try, no matter how careful the owner is. Careful owners shrink the odds. They cannot shrink the number of doors.

Three common myths about a hacked site

• Plugins. The myth: Careless owners skip the updates. The reality: Updates matter, but a plugin is someone else's code, and its fixes arrive on its author's schedule.
• Database. The myth: A contact form is a harmless box on a page. The reality: A form hands what a visitor types to code and a database behind it. That path is open to anyone who finds the form.
• Server code. The myth: A page is just a page. The reality: On a site like this, code runs to build each page when someone asks. Running code is something an attacker can aim at.

The careless owner explanation fails a simple test. Hand the same site to the most careful person you know and the same three doors are still there. Care helps with each one, and we will get to how. It does not remove them.

Notice what the myth does. It puts the problem on the person who can least see it. An owner cannot read plugin code or inspect a database. Blaming habits is easy. Counting doors is more useful. So the first question is not who was careless. It is how many doors this site has, and who is watching each.

Door one: plugins written by outsiders

A plugin is add-on code that gives a site a feature, such as a booking form or a photo gallery. Usually someone outside your business wrote it, and that person decides when fixes ship. We think each plugin is another party's code you have to trust and keep updated.

That arrangement is normal. A booking form from a careful author can be a good choice. Each plugin still adds a party to the chain, and the chain is only as current as its slowest link.

• Step 1: A flaw is found in a plugin. Someone spots a mistake in the plugin's code.
• Step 2: The author ships a fix. The author, not you, decides when.
• Step 3: The fix is public. The fix and its notes can show what was wrong.
• Step 4: Your site waits. Until someone installs the update on your site, the old code is still there.

Step four is the gap. It is where owners get blamed, yet closing it takes a person with access and a schedule, and the fix itself arrives on a stranger's schedule. If we were asking questions of any site with plugins, we would start with who checks for updates, and how often. A plugin that nobody owns is a door that nobody watches.

Doors two and three: the database and the server code

The database is where a site stores what visitors send it, such as names, phone numbers and messages. The server code is the program that reads that data and builds each page on each visit. A site with both has more places an attacker can aim at, and each one needs updates.

Think of the database as the filing cabinet behind your contact form. The form is the handle, the code is the lock, and the cabinet holds what your customers typed. A mistake in the lock is the whole problem. That is why a form is more than a box on a page.

One request, two designs

A site that builds each page

1. Visitor: Asks for a page
2. Server code: Runs for the request (A mistake here is a way in)
3. Database: Looks up the content (Form input reaches it)
4. Page: Built, then sent

Code runs on each visit.

A site of finished pages

1. Visitor: Asks for a page
2. Host: Finds the saved file and sends it

A saved file is sent.

Count the red rings. Each one is a part that needs updates and a place to aim at.

In the first lane, a visitor's request wakes up code and a database before a page exists. Each of those is a part that can have a flaw and a part that needs updates. For one named flaw in server software, read our post on a flaw in the server software WordPress runs on. That post covers a single flaw. This one is the map.

What a site of finished pages leaves out

A site of finished pages is built ahead of time and served as saved files. It has no plugin layer, no database on the page host and no code running per visit. That does not make it perfect, since hosting and logins still need care. In our view, it removes three places an attacker would look. If it has a contact form, the form posts to a service that stores the message, so that service is one more party to ask about.

Built on each visit

• Plugins: Fixes arrive on the author's schedule (Needs updates)
• Database: Holds what visitors send (Runs on request)
• Page-building code: Runs on each visit (Runs on request)
• The page: Built fresh for the request

Plugins, a database and page code to keep current.

Finished pages

• Finished page files: Built ahead of time (Nothing to run)
• Hosting and logins: Still need care (Needs updates)

Saved files on a host.

Count the flagged layers in each window. Fewer layers means fewer things to forget.

A site of finished pages, such as one built with Astro and served from Vercel, sends a saved file when someone asks for a page. We keep permanent measurement in the site code, where each build can check it, and we leave the tag manager only short-lived ad tags, checked each quarter, as we explained in our post on keeping permanent analytics in the code. We think a tag container is the same kind of door as a plugin: code someone else can change on your page. The longer story is on the page about how we build service sites.

Our view of the parts you carry. Ask your web person to fill in the middle column for your own site.

Read the table as a list of chores, not a scoreboard. Fewer parts to keep current means fewer chances to forget one.

Here is our rule of thumb, and you can borrow it: count the moving parts a site exposes. Plugins, a database and per-visit code each count. A parts count will not tell you whether a site is safe, but it shows how much there is to watch. We think that count is the right first step when you Optymize a site.

Three questions to ask your web person

Ask your web person which plugins run on the site and who updates them, what database sits behind your forms, and what code runs each time a page loads. Clear answers name a person and a schedule. Vague answers often mean nobody is watching the doors, and that is the first thing to fix.

Three questions, three doors

1. Plugins: who updates them?
2. Database: what sits behind forms?
3. Server code: what runs per visit?
4. Know your doors

You do not need to be technical to ask, and you do not need to catch anyone out. You are looking for a short answer from a person who knows. If the answer takes a week, that delay is your answer.

If you run a locksmith company and want a site with fewer doors to watch, see what we build for locksmith companies. The habit behind it is the one from our post on testing a site on phones before it ships: look at the real thing instead of trusting the promise.

Do this week

• Ask your web person to list the plugins on your site.
• Ask who updates each plugin, and how often.
• Ask what database sits behind your contact form.
• Ask what code runs when a page loads.
• Write the answers down and keep the note.

Originally published at optymizer.com.

Want a second set of eyes on this for your business? Talk to Offer. Optymizer was founded in 2011, and I take the first call myself.

Human intelligence, assisted by AI. Offer has run digital marketing for 20 years. AI just helps him say it faster.