Security in WordPress from the server (not just plugins)

WordPress powers a huge part of the current web. Personal blogs, corporate websites, online stores, and critical projects depend on it every day. That popularity has a direct consequence: WordPress is one of the preferred targets for automated attacks.

For years, the usual response has been the same: install one or more security plugins and trust them to do their job. And while plugins are useful, they cannot be the foundation of a solid security strategy. They act when WordPress is already running and, in many cases, when the damage has already begun.

The security of a well-protected WordPress starts earlier. It starts on the server. In how it is configured, what services it exposes, how it manages permissions, what traffic it allows, and how it responds to anomalous behaviors.

In this guide, we will address WordPress security from the server, explaining how hardening really works, what threats exist, how they are mitigated from the infrastructure, and why hosting is a key piece. It is not a list of commands to copy and paste, but a complete explanation so you understand what you are protecting and why.

Introduction: Why plugins are not enough for WordPress security

Before talking about servers, it is worth dismantling a widespread idea: installing several security plugins does not equate to having a secure WordPress.

Many WordPress sites rely solely on one or more plugins for their security. The problem is that these tools act when WordPress is already loaded and running. If the server is vulnerable or poorly configured, the attack can occur even before the plugin has a chance to intervene.

Moreover, plugins depend on the CMS itself. If WordPress is compromised, the plugin can also be affected. Therefore, basing all security on the application implies taking unnecessary risks.

Some common limitations:

• Resource consumption: firewalls and scanners in PHP can slow down the web
• Late detection: many attacks have already done damage when detected
• Dependence on the CMS: if WordPress fails, the plugin does too
• Function overlap: too many plugins increase the attack surface

Infrastructure plays a key role. A poorly configured server amplifies any vulnerability; in that context, no plugin can compensate for an insecure foundation.

Effective security is based on layers. And the first layer is always the server.

A well-protected server can:

• Block attacks before they reach WordPress
• Limit damage even if the CMS has flaws
• Protect all hosted sites, not just one

WordPress security at the server level: the correct approach

When we talk about protecting WordPress from the server, we are not talking about “doing strange things.” We are talking about applying basic computer security principles to a real web environment.

Effectively protecting WordPress involves looking beyond the admin panel. Server-level security focuses on strengthening the infrastructure that supports the website, reducing risks before traffic reaches the CMS.

Opting for a WordPress security strategy without plugins does not mean giving them up, but understanding that the most effective protection starts outside the CMS. When the server is well protected, WordPress operates in a controlled and stable environment. The goal is not to complicate management, but to make attacking your site difficult, costly, and unprofitable.

What does it mean to protect WordPress from the server?

Protecting WordPress from the server means applying security measures to the operating system, services, network, and storage. Protecting WordPress from the server involves working on several levels:

• Operating system
• Active services
• Web stack (Apache/Nginx, PHP, database)
• File system
• Network and firewall
• Monitoring and backups

All this happens before WordPress processes a single request.

Differences between application security and infrastructure security

Application security protects what happens inside WordPress.
Infrastructure security protects everything that happens before. The difference is key:

• Application security: validates forms, detects malware, manages access
• Infrastructure security: controls who can reach, what can be executed, and what is automatically blocked

One does not replace the other, but infrastructure sets the limit of possible damage.

Advantages of a server-side approach versus plugin-based solutions

A server-based approach offers clear advantages:

• Early blocking of automated attacks
• Less impact on performance
• Global protection of the environment
• Less dependence on external software

Server hardening: the foundation of a secure WordPress

Server hardening consists of eliminating weak configurations and minimizing entry points. It is an essential practice for any WordPress that aims to be stable, fast, and secure.

A hardened server is not more complex to use, but much more difficult to attack.

Updating and maintaining the operating system

Most automated attacks exploit known vulnerabilities. If the system is not updated, the attack does not need creativity.

Best practices:

• Apply security patches regularly
• Keep critical libraries updated
• Remove unnecessary packages
• Use versions with active support

Secure configuration of the web stack

A secure web stack is not the most complex, but the most controlled.

Key aspects:

• Apache or Nginx with minimal modules
• PHP with dangerous functions disabled
• expose_php = Off
• Reasonable memory and execution limits
• Database accessible only from localhost

Each adjustment reduces possibilities of abuse.

Disabling unnecessary services and ports

Reducing active services implies fewer entry doors. Every active service is a potential entry point.
Closing what is not used is one of the most effective and least applied measures.

Common examples:

• Open ports without real reason
• Unencrypted FTP
• Forgotten old services

Use of optimized and secure PHP versions

PHP is the heart of WordPress. Using obsolete versions is one of the most common mistakes.

Recommendations:

• PHP 8.x with support
• Disable dangerous functions if not used
• Correctly configure open_basedir, disable_functions, and execution limits

File and directory permissions in WordPress

Proper permission management is one of the most important—and most ignored—pillars of WordPress security. It doesn’t matter whether you work with a dedicated server or shared hosting: the permissions and ownership of the files determine who can read, modify, or execute each part of your web.

Many common problems in WordPress, from unexpected errors to malware infections, originate from poorly configured permissions. Moreover, an adequate permission policy prevents technical failures and drastically reduces the impact of potential attacks, as it limits what an attacker can do even if they manage to access the system.

Why poor permission management is a critical risk

When permissions are too permissive, WordPress leaves unnecessary doors open. This can allow:

• Modification of critical system files
• Injection of malicious code into themes or plugins
• Execution of scripts in directories where it should not be possible
• Malware persistence even after cleaning the installation

On the other hand, excessively restrictive permissions also create problems. WordPress needs to write to certain files and folders to update, install plugins, or manage content. The balance between security and functionality is key.

Recommended permissions for WordPress files and folders

A secure WordPress installation should allow the CMS to function correctly without exposing more than necessary. These are the recommended permissions:

Directories

rwx-wx-wx

This allows:

• Owner: read, write, and access
• Group and others: access to traverse directories

It is sufficient for WordPress to function without allowing unnecessary modifications.

Files

rwxr--r--

Recommended configuration for:

• WordPress core
• Themes
• Plugins

Allows WordPress to update but prevents third parties from modifying sensitive files.

wp-config.php

rw-------

This file contains:

• Database credentials
• Security keys
• Critical configuration

Restricting its access is one of the most important hardening measures in WordPress.

Protection of sensitive files (wp-config.php, .htaccess)

Some elements of the WordPress structure are especially attractive to attackers:

• wp-config.php: main target for stealing credentials
• wp-admin/: access to the control panel
• wp-content/: themes, plugins, and uploads
• uploads/: frequent entry point for malware

From the server, rules should be applied to limit:

• Execution of scripts in upload folders
• Direct access to sensitive files
• Modification of core files

Prevention of malicious code execution

One of the most common attack vectors is uploading seemingly innocent files (images, PDFs) that actually contain malicious code.

A key best practice is to prevent the execution of scripts in directories like /wp-content/uploads/. Even if the attacker manages to upload a malicious file, they will not be able to execute it, which stops the attack in its tracks.

This measure, combined with correct permissions, eliminates a large part of the common infections in WordPress.

Protection against attacks from the server

Once the server is properly hardened and permissions are well defined, the next step is to protect WordPress against the real attacks that occur every day on the Internet. We are not talking about theoretical scenarios, but automated attempts that affect thousands of sites daily, whether they contain sensitive content.

The advantage of acting from the server is clear: attacks are blocked before consuming resources, before loading WordPress, and in numerous instances, even before the attacker knows if the site exists.

Most common attacks on WordPress

Most attacks against WordPress follow very specific and repetitive patterns. This allows them to be anticipated and mitigated quite effectively from the infrastructure.

Among the most common are:

• Brute force attacks, mainly targeting wp-login.php and /wp-admin/, where bots try user and password combinations en masse.
• SQL injections, attempting to exploit poorly validated forms or vulnerable plugins to access the database.
• Cross-Site Scripting (XSS), by inserting malicious scripts into input fields like comments or forms.
• Malicious file uploads, usually disguised as images or documents.
• Persistent malware, designed to remain hidden and reinfect the site after superficial cleanings.

The important thing here is to understand that these attacks are usually not manual, but automatic. And the automatic can be blocked automatically.

Limiting login attempts and protecting wp-admin

The WordPress admin area is one of the most attacked points. Although there are plugins to protect the login, doing it from the server adds a very effective prior layer.

Some common server-level measures are:

• Limit the number of login attempts per IP
• Restrict access to the admin panel by country or IP range
• Add additional authentication before reaching WordPress
• Reduce the visibility of known paths like wp-login.php

These measures do not replace good user and password management, but greatly reduce the noise of automated attacks.

Blocking malicious IPs and suspicious traffic

Server log analysis allows detecting anomalous behaviors: too many requests in a short time, repeated access attempts, or clearly automated patterns.

Tools like automatic IP blocking systems allow:

• Detect attack attempts in real-time
• Block the attacker for a determined period
• Prevent the server from continuing to consume unnecessary resources

From a security standpoint, this is key: an attack that does not reach WordPress is an attack that does not exist.

Mitigating DDoS attacks at the hosting level

Denial-of-service attacks cannot be solved from WordPress. Their mitigation must be done before the traffic reaches the server, filtering anomalous connections and artificial peaks.

Here the role of hosting is fundamental, as only from the network infrastructure can this type of traffic be absorbed or filtered without affecting the site.

Firewall and perimeter security

Perimeter security is the border between your WordPress and the rest of the Internet. A well-configured firewall acts as a smart filter, allowing legitimate traffic and blocking suspicious requests before they enter the system.

This approach not only improves security but also performance, as it reduces the number of requests the server must process.

What is a firewall, and why is it key in WordPress

A firewall analyzes incoming connections and decides what is allowed and what is blocked according to defined rules. These rules can be based on:

• IPs
• Countries
• URL patterns
• Request types
• Signatures of known attacks

In the context of WordPress, the firewall is especially useful for stopping massive and repetitive attacks.

WAF (Web Application Firewall): specific protection for web applications

A WAF is a type of firewall specifically designed for web applications. Instead of analyzing only connections, it analyzes the content of HTTP requests.

A WAF oriented to WordPress can detect and block:

• SQL injections
• XSS
• Brute force
• Bots looking for known vulnerabilities
• Malformed or suspicious requests

The great advantage of the WAF is that it does not depend on WordPress. It acts even if the CMS is down or compromised.

Differences between server firewall and application firewall

Both fulfill different and complementary functions:

• Server firewall: protects the entire system, regardless of the application.
• Application firewall (WAF): specifically protects WordPress and other web applications.

The combination of both offers much more robust protection than either of them alone.

Backups and incident recovery

A complete security strategy is not only based on preventing attacks but also on assuming that something will fail someday. It could be an attack, human error, or a faulty update. At that moment, backups make the difference.

Backups are one of the most important pieces of any WordPress security strategy. They do not prevent attacks but make the difference between a scare and a total loss. However, they are also one of the most misunderstood aspects.

Having backups does not automatically mean you can recover your website in any situation. For a backup to be truly useful, you need to understand how it works, what it covers, and, above all, what it cannot solve.

Why backups are an essential part of security

Without backups, any incident can become a total loss. A backup does not prevent the attack, but it does prevent its most serious consequences.

Backups are essential for:

• Minimizing downtime
• Recovering from infections
• Reversing human errors
• Restoring the site after critical failures

Automatic backups from the server

Automatic backups at the hosting level are fundamental and should be a minimum standard. They allow:

• Restoring the website after recent errors
• Recovering files accidentally deleted
• Rolling back after a problematic update

In cdmon, for example, these backups are performed daily and automatically, without the user having to intervene. This covers most of the common day-to-day incidents. You can see more information about how our backups work at the following link:
👉 Backups at cdmon: Your website always safe, without complications

External storage and quick recovery

This is where many backup strategies fail, not due to lack of technology, but due to false expectations. Having automatic backups does not guarantee that there is always a clean copy to revert to.

Imagine a very common scenario in WordPress: the website is discreetly infected, continues to function with apparent normality, and does not generate visible alerts. For weeks—or even months—no one detects the problem. Meanwhile, the automatic backup system continues to run normally, backing up a website that is already compromised.

When the infection is finally detected, all available copies contain the same malware. At that point, there is no “good” backup to restore, and recovery becomes much more complex. This is not a failure of the backup system, but a direct consequence of detecting the problem too late.

For this reason, in addition to the automatic hosting backups, it is highly recommended to maintain external copies under your control. It is not about making constant backups but about having independent restore points, stored outside the server.

These copies can be:

• Backups downloaded and stored locally
• Copies on an external hard drive
• Backups on a NAS
• External storage separate from the production server

A well-managed external copy allows quick recovery of the site when the problem is identified, without relying solely on the retention of automatic backups.

Both approaches do not compete; they complement each other:

• Automatic hosting backups are ideal for recent errors and quick recovery
• External copies are key for persistent infections and critical attacks

A mature strategy combines both, assuming that no single solution covers all scenarios.

Backup strategy against ransomware and critical attacks

The real value of an external copy becomes even more evident in severe scenarios, such as ransomware attacks or complete server compromises. In these types of incidents, the attacker’s goal is not just to infect the website, but to prevent you from recovering it.

If ransomware encrypts files, blocks access, or compromises the entire environment, backups stored on the same system can be affected or become inaccessible. In these cases, the only real recovery path is to have physically isolated copies.

A backup strategy designed for critical attacks must assume that:

• The server may become completely unusable
• Local copies may not be accessible
• Restoration must be done from an external and secure environment

This is where a physical or external copy becomes the last line of defense. It allows restoring the site and doing so without dragging compromised configurations or relying on systems affected by the attack.

In security, this approach is known as offline or air-gapped backup: copies that are not permanently connected to the production environment and therefore cannot be encrypted or altered by a remote attack.

Monitoring, logs, and early threat detection

One of the most significant differences between an “apparently secure” WordPress and a truly protected one is the ability to detect problems before they become visible. Many attacks do not seek to take down the website immediately, but to go unnoticed for as long as possible.

Monitoring and log analysis allow understanding what is really happening on the server, beyond what is seen from the WordPress panel. It is a silent security layer, but absolutely fundamental in any professional environment.

Importance of continuous server monitoring

Continuous monitoring is not just about knowing whether the website is down or not. It goes much further. It involves observing patterns, behaviors, and deviations from the norm.

Thanks to proper monitoring, it is possible to detect:

• Anomalous traffic spikes
• Unexpected increases in resource consumption
• Repetition of failed accesses
• Suspicious requests to specific routes
• Behavior changes on the server

The sooner an anomaly is identified, the more room there is to act without the problem escalating.

Log analysis to detect suspicious access

Server logs record practically everything that happens: accesses, errors, requests, responses, and anomalous behaviors. Analyzing them allows seeing what WordPress, by itself, does not show.

The problem is that, without adequate tools, logs tend to be:

• Difficult to interpret
• Fragmented into multiple files
• Not easily accessible for continuous analysis

Therefore, centralizing and visualizing logs is key. Tools like ConnectiLogs allow centralized analysis of server logs, facilitating the detection of suspicious patterns and offering a clear view of the site’s real behavior.

If you want to know how this approach works and why having logs under control makes a difference, you can find more information here:
👉 ConnectiLogs: Be your own data analyst and keep control of your data

Alerts and quick response to incidents

Monitoring is only useful if accompanied by alerts and response capability. It is useless to have data if no one reviews it when something anomalous occurs.

A well-configured alert system allows:

• Notifying suspicious access attempts
• Detecting repetitive errors in a short time
• Identifying ongoing brute force attacks
• Acting before the site is affected

The speed of response is, often, what differentiates a minor incident from a serious problem.

Prevention against persistent attacks

Not all attacks seek an immediate impact. Many attackers prefer to maintain access for as long as possible, acting discreetly to avoid raising suspicion. These are called persistent attacks.

In this type of attack, the goal is usually to:

• Keep backdoors active
• Reinfect the site after superficial cleanings
• Use the server for other purposes (spam, DDoS, redirects)

Prevention against persistent attacks does not depend on a single measure, but on the combination of monitoring, log analysis, and change detection.

Observing patterns like:

• Recurrent accesses from the same IPs
• Periodic file modifications
• Requests to unusual routes
• Activity outside normal hours

allows detecting behaviors that, individually, might go unnoticed, but together reveal an underlying problem.

The role of hosting in WordPress security

After analyzing all the security layers—hardening, permissions, firewall, monitoring, and backups—there is a clear conclusion: many of these measures should not depend on WordPress itself.

The most effective security is applied before traffic reaches the CMS, and that places hosting as a key piece in any serious protection strategy. In a mature WordPress hosting security strategy, the provider ceases to be a mere host and becomes an active layer of protection against attacks and critical failures.

Isolation of accounts and environments

One of the most important aspects—especially in shared hosting—is the isolation between accounts. Without adequate isolation, a compromised site can affect others hosted on the same server.

A secure hosting must ensure that:

• Each account is isolated at the system level
• Resources are not shared insecurely
• An incident does not spread between projects

This isolation is a silent but fundamental layer to prevent cross-infections and chain security problems.

Updated infrastructure and specialized support

Security is not a fixed state but a continuous process. Therefore, in addition to technology, it is crucial to have technical teams that maintain and supervise the infrastructure constantly.

This includes:

• Application of security patches
• Continuous system optimization
• Quick response to incidents
• Preventive risk analysis

When a problem occurs, the difference between hours or days of downtime is usually in the response capability of technical support.

What a secure hosting for WordPress should offer

A security-oriented hosting does not limit itself to offering disk space and a database. It must incorporate active protection measures in terms of infrastructure, transparently for the user.

Among the key features it should include are:

• DDoS attack prevention, filtering malicious traffic before it affects the server
• Automatic detection and blocking systems against suspicious behaviors
• Daily automatic backups, isolated from the production environment
• Proactive monitoring of systems and services
• Continuous updates of the operating system and web service
• Malware scanning and detection at the server level

Such measures reinforce security and relieve WordPress itself of responsibility, avoiding the need to rely on multiple plugins for tasks that should be resolved in the infrastructure.

If you want to see how these protections are applied in a real environment, at cdmon we explain in detail the security measures integrated into our infrastructure:
👉Protect your page and your clients’ data

Certifications and compliance with security standards

Beyond technical measures, there are certifications that certify that a provider complies with recognized information management and security standards. These certifications are not just a seal, but the result of audits and continuous processes.

In the case of cdmon, the infrastructure complies with standards such as:

• ISO 9001, oriented to quality management
• ISO 14001, focused on environmental management
• ENS medium level (National Security Scheme)

The ENS is especially relevant for projects that require a high level of trust, as it establishes strict measures to protect information and systems against common threats.

Additional best practices to enhance WordPress security

After working on security from the server, infrastructure, and monitoring, there is still a key factor: how WordPress is used daily. Many breaches do not occur due to complex technical failures but due to small and cumulative decisions.

These best practices do not replace server-side measures but help the entire system function coherently and securely in the long term.

Secure access and enhanced authentication

Access to the admin panel remains one of the most sensitive points of any WordPress. Although the server filters much of the malicious traffic, credentials remain a critical door.

Some basic but essential practices:

• Use of unique and strong passwords
• Two-factor authentication for users with elevated permissions
• Elimination of accounts that are no longer used
• Periodic review of roles and privileges

Reducing who can access and from where automatically reduces risk, even if there is a temporary vulnerability.

Use of HTTPS and SSL certificates

The use of HTTPS is no longer a recommendation: it is a basic requirement for any WordPress that wants to be secure and reliable. HTTPS encrypts the communication between the user’s browser and the server, preventing Man-in-the-Middle attacks, credential theft, and data manipulation in transit.

A well-configured WordPress should:

• Always use HTTPS
• Force redirection from HTTP
• Avoid mixed content (resources loaded without encryption)
• Use valid and updated SSL certificates

It is not enough to install an SSL certificate. If the website is still accessible via HTTP, an insecure entry point remains that can be exploited. Therefore, redirecting all traffic to HTTPS is an essential part of security, not just an aesthetic or SEO improvement.

From the server, this redirection ensures that any request arrives already encrypted to WordPress, reducing risks even before the CMS processes the request. Additionally, it improves user trust and avoids security warnings in browsers.

If you need help configuring this redirection correctly, at cdmon you have a step-by-step guide where we explain how to do it safely:
👉 How to redirect HTTP to HTTPS with an SSL certificate

Minimizing the attack surface

Each plugin, theme, or additional functionality increases the site’s attack surface. This does not mean avoiding plugins, but choosing them wisely.

Best practices in this regard:

• Install only necessary plugins
• Remove plugins and themes that are not used
• Prioritize maintained and updated software
• Avoid duplicate solutions

A simpler WordPress is almost always a more secure and stable WordPress.

Awareness and user management

Finally, the human factor. Many security incidents do not originate from sophisticated attacks, but from usage errors: reused passwords, shared access, or lack of awareness of basic risks.

Raising user awareness involves:

• Explaining minimum best practices
• Avoiding unnecessary access
• Promoting safe habits

Technology can set barriers, but people are still part of the system.

Conclusion

Throughout this guide, we have noted that protecting WordPress is not about accumulating security plugins but about understanding how the different layers that support a website work. Plugins can help, but they act when WordPress is already running. Real protection starts earlier, on the server.

Throughout this guide, we have seen that:

• The server is the first line of defense
• Hardening reduces risks before they appear
• Permissions limit the impact of an attack
• The firewall and monitoring allow anticipation
• Backups save projects but have limits
• Hosting plays an active role in the entire process

Effective security is not reactive. It is preventive, progressive, and aware of its limitations. There is no zero risk, but there are strategies that greatly reduce the probability and impact of an incident.

In a mature WordPress hosting security strategy, the server is not a secondary element; it is the fundamental pillar of security. A well-configured server can block automated attacks, limit the impact of specific vulnerabilities, and facilitate recovery from serious incidents. Without this foundation, any measure applied only at the application layer will always be reactive.

If your WordPress is a serious project, it deserves security accordingly. Opting for secure, professional, and managed hosting, which integrates these protections into infrastructure, is not an extra: it is an essential part of the strategy. Because security should not depend solely on what you install but on where and how your web is run.