WAF Enabled, Foreign IPs Blocked—What Other Doors Does WordPress Have?

The hosting provider’s Web Application Firewall is enabled. HTTPS is working. You’ve even restricted access to your WordPress login page from overseas IP addresses.

Surely that should be enough to keep most attackers out?

That’s what I wanted to believe. But after examining WordPress’s official security documentation, I found something rather unsettling: securing the login page does not necessarily close the other routes through which a website can be attacked.

If your hosting company already provides security protection, why does a WordPress site owner still have so much to worry about?

The answer involves more than weak passwords. There are separate authentication systems, plugin vulnerabilities, hosting control panels, and even situations where several apparently independent websites share access to the same database.

So I compared the official documentation, examined four potential attack paths, and calculated what different backup schedules could mean for a frequently updated site.

AI-generated conceptual illustration. It represents the need to secure alternative authentication and administration routes, not an actual server facility or documented intrusion.

A WAF Isn’t an All-Powerful Security Guard

Let’s start with the Web Application Firewall (WAF) provided by many hosting companies.

A WAF examines web traffic and attempts to detect or block malicious requests. It can be an effective layer of protection against attacks on WordPress.

But it cannot guarantee that every malicious request will be stopped.

Consider an outdated plugin with a security vulnerability. Depending on the flaw, an attacker might exploit it without ever logging into the WordPress dashboard. A WAF may recognize and block the attempt, but that depends on the attack and the protection in place.

HTTPS is important too, although it serves a different purpose: it primarily protects information in transit between the browser and server. It does not repair vulnerable WordPress code.

And the familiar login page is only one part of the picture.

Potential attack path	Main protections to check
WordPress login	Two-factor authentication and strong, unique passwords
Vulnerable plugins	Security updates, removal of unused plugins, and WAF protection
Hosting control panel	Separate two-factor authentication for the hosting account
External applications and integrations	Credential management and revocation of unused access

This table is our editorial breakdown of four attack paths, based on official WordPress and hosting-control-panel documentation. These are different types of risk, not four equally likely methods of intrusion.

One particularly easy-to-overlook feature is Application Passwords, introduced in WordPress 5.6 in December 2020.

Application Passwords let external tools authenticate to WordPress for tasks such as publishing posts or uploading media. They are separate from the password used to log into the dashboard through a browser.

Even if your WordPress dashboard requires two-factor authentication, that protection does not automatically extend to every application credential used by an external service.

These credentials are useful and can be revoked individually, but they still require proper management.

The hosting control panel introduces another distinction. For example, cPanel provides its own two-factor authentication system, separate from WordPress.

Its official documentation also explains that API requests using password authentication may bypass the usual 2FA challenge if the hosting provider has not enabled the appropriate API security policies.

So there is more than one lock to check.

Does Blocking Foreign IP Addresses Really Keep Attackers Out?

For someone who manages a website exclusively from Japan, restricting WordPress logins to Japanese IP addresses can be a useful additional precaution.

The same idea applies elsewhere: a site administered only from one country may benefit from restricting unnecessary foreign login traffic.

However, an IP address identifies a network connection, not the actual identity or nationality of the person using it.

An attacker using a compromised machine, a proxy server, or another connection within an allowed country may appear to be connecting from an approved location.

That means country-based blocking cannot replace proper authentication.

WordPress’s official guidance on brute-force attacks cautions against relying on permanent country blocklists. They can block legitimate users and become difficult to maintain. The documentation instead emphasizes protections such as two-factor authentication, rate-limiting login attempts, and keeping software updated.

None of this means geographic restrictions are worthless. They can reduce unwanted traffic when properly configured.

But reducing the number of possible entry points is not the same as verifying who is trying to enter.

Four Separate Domains, One Shared Key? The Database Question

Here is the detail that bothered me most.

When you operate several WordPress websites under different domains, it’s tempting to think of them as separate properties.

Different addresses, different dashboards, different content. Surely one site’s security problems shouldn’t automatically affect another?

Not necessarily.

According to WordPress’s official installation documentation, multiple independent WordPress installations can share a single MySQL database. Each installation can distinguish its tables using a different table prefix.

For example, four websites might use prefixes such as sitea_, siteb_, sitec_, and sited_.

Those prefixes keep the tables identifiable. They do not, by themselves, restrict which tables a database account can access.

Now consider a hypothetical setup with four WordPress installations.

If all four use the same database account, and that account has privileges covering every site’s tables, compromising those credentials could expose data belonging to all four sites.

Hypothetical four-site configuration	Potential access using one set of database credentials
All four sites share one database user	Up to all four sites, assuming the account has privileges over every relevant table
Each site has its own database and database user	Generally limited to one site’s database, provided permissions are correctly restricted

This is a comparison of possible access privileges, not a calculation of hacking probability or a claim that four websites would necessarily be compromised together.

There is an important qualification: WordPress also supports multiple installations sharing one database while using different MySQL users. With carefully limited table privileges, access can be separated even inside the same database.

So sharing a database is not automatically the same as sharing unrestricted access.

What matters is which credentials are shared, and exactly what those credentials are permitted to access.

And there is another complication.

Even if every site uses a different database account, their WordPress files may still be accessible through a shared hosting-system account. If that account can read multiple sites’ configuration files, the database separation alone may not contain a compromise.

Different domain names do not necessarily mean separate database permissions or isolated file access.

WordPress’s security-hardening guidance recommends considering separate databases managed by different users when operating multiple blogs on the same server. It describes this as a way to help contain the damage if one installation is compromised.

AI-generated conceptual diagram of four independent WordPress installations sharing one database. It does not represent a literal server layout. Separate database users and appropriately restricted permissions can also be configured within a shared database.

Daily vs. Weekly Backups: How Many Posts Could You Lose?

Security doesn’t end with preventing unauthorized access. If something goes wrong, how much work can you actually recover?

Hosting companies often offer automated backups, but the existence of a backup tells us very little about how recent it is or what it contains.

To make the difference more concrete, I ran a simple calculation.

Assumption: A WordPress site publishes two posts every day. Backups are created successfully at fixed intervals, and a failure occurs immediately before the next scheduled backup. Any posts added since the previous usable backup cannot be recovered from another source.

Backup interval	Maximum posts potentially lost under this scenario
Every day	2 posts
Every 3 days	6 posts
Every 7 days	14 posts

The arithmetic is straightforward:

2 posts per day × 7 days = 14 posts.

Compared with daily backups, weekly backups could leave seven times as many newly published posts unrecoverable in this particular worst-case scenario.

That doesn’t mean a weekly backup will cause the loss of 14 posts. Actual losses depend on publishing times, when the incident occurs, whether additional backups exist, and what can be recovered elsewhere.

The calculation simply puts a number on something easy to overlook: backup frequency determines how far back you may have to go.

WordPress also requires more than a database backup. Its database holds posts and other content, while uploaded images, themes, plugins, and other important files live in the filesystem.

A usable recovery plan needs to account for both.

Even if your hosting provider offers automatic backups, retention periods, recovery options, and the files included depend on the service.

Independent backup copies and a tested restoration procedure are therefore worth having.

So What Should WordPress Owners Check First?

After comparing these different security functions, my first priorities would be fairly practical.

Check that administrator accounts have strong passwords and two-factor authentication. WordPress core does not include built-in 2FA, so this usually requires a suitable plugin or identity provider.

Make sure the hosting control panel has its own protections. Review unused administrator accounts and external application credentials. Keep WordPress, themes, and plugins updated, and remove extensions that are no longer needed.

If you operate multiple WordPress installations, there’s also a question worth asking your hosting provider:

Are file permissions isolated between my sites, and can each installation use a separate database account with restricted privileges?

Some protections belong primarily to the hosting provider, particularly the underlying infrastructure and isolation between separate customers.

Others depend on how the WordPress owner configures accounts, installs plugins, grants access, and manages backups.

Neither party can simply assume that the other has taken care of everything.

Editor’s Note

I used to think that enabling a WAF and restricting overseas logins went a long way toward settling the security question.

They certainly help. But once I started digging, I found a rather annoying collection of other things to check: the hosting dashboard, external integrations, plugin vulnerabilities, and even the permissions shared between websites sitting under the same hosting account.

The database question was especially irritating.

From the outside, four domains look like four different properties. But if they all use the same database credentials with access to every table, it’s rather like discovering that four separate shops share the same key to the back room.

That’s not automatically a disaster. It is, however, something I would want to know before handing over the keys.

Nor do I think website owners should be expected to take responsibility for every server-level security issue. Some problems can only be addressed properly by the hosting provider.

What bothers me is not that responsibility is shared. It’s that the boundary is so easy to overlook.

In the end, counting how many security features you have enabled tells you less than asking a much less glamorous question:

Which entrance is each security measure protecting, and who’s responsible for the ones it doesn’t cover?

That’s where the real story is.

Terms That May Need a Quick Explanation

References