WordPress hosting security best practices are a set of server-level and site-level controls that work together to prevent unauthorized access, data theft, and malware infections. WordPress powers over 43% of all websites on the internet (W3Techs), making it the single most targeted CMS by automated attack scripts. Security researchers recorded 7,966 new WordPress ecosystem vulnerabilities in 2024 alone, a 34% increase over the prior year, with 96% of those flaws found in third-party plugins. If you run a WordPress site, understanding these threats and applying the right protections is not optional. This guide covers every critical layer of WordPress hosting security, from choosing the right host to hardening your server configuration, so you can protect your site, your customers, and your reputation.
Why WordPress Hosting Security Matters More Than Ever
WordPress hosting security matters because WordPress is simultaneously the world’s most popular CMS and its most targeted platform. The scale of the threat is measurable. In 2024, WordPress sites face near-constant automated attack attempts, with security researchers estimating attacks occur every few minutes on average, but the threat remains constant and evolving.
Quick Answer: WordPress hosting security matters because 43.5% of all websites run on WordPress, making it a primary target for automated attacks. In 2024, researchers discovered 7,966 new vulnerabilities in the WordPress ecosystem, with 96% originating in third-party plugins. A single unpatched vulnerability can expose customer data, trigger Google blacklisting, and cause irreversible reputational harm.
The consequences of a successful attack extend well beyond a temporary outage. Sucuri tracked over 500,000 infected websites in 2024. Google blacklists approximately 10,000 websites every day for malware distribution. An infected site can see organic search traffic drop to zero within hours of being flagged. For ecommerce sites built on WooCommerce, a breach can trigger PCI DSS compliance violations and expose payment data.
The Three Layers of WordPress Security Risk
WordPress security risk operates across three layers:
- Hosting infrastructure: Server configuration, software versions, firewall rules, and data center physical security
- WordPress application: Core files, plugin code, theme code, and database configuration
- User behavior: Password strength, user role management, and software update habits
Addressing only one or two layers leaves your site vulnerable. A truly secure WordPress setup requires all three layers working together.
How to Choose Secure WordPress Hosting
Choosing secure WordPress hosting requires evaluating server-level protection features, not just price and storage. Your hosting provider controls the infrastructure beneath your WordPress installation. If that infrastructure is misconfigured or under-resourced on security, no plugin can fully compensate for server-level weaknesses.
Quick Answer: Secure WordPress hosting includes built-in firewalls, automatic malware scanning, DDoS mitigation, isolated hosting environments, and server-side software kept current with security patches. Shared hosting environments where one compromised site can affect others on the same server represent the highest-risk hosting option for WordPress.
Key Security Features to Require from Any WordPress Host
Look for these specific capabilities before committing to a hosting provider:
| Security Feature | Why It Matters | Risk if Missing |
| Web Application Firewall (WAF) | Blocks malicious traffic before it reaches WordPress | Unfiltered attacks hit your application directly |
| Automatic malware scanning | Detects infections before they spread | Infections can go undetected for weeks |
| DDoS protection | Keeps site available during volumetric attacks | Site goes offline, revenue and trust lost |
| Isolated environments | Prevents cross-site contamination | One hacked site on server can compromise others |
| Automatic server-side updates | Keeps PHP, MySQL, and OS patched | Outdated server software creates known exploits |
| Free SSL certificate | Encrypts data in transit | Data exposed, Google marks site as “Not Secure” |
| Testing workflow | Tests updates safely before going live | Updates can break site or introduce vulnerabilities |
| Automated backups | Enables clean recovery after an attack | No recovery option if site is wiped |
Our managed WordPress hosting includes all of the above features as standard. The hosting environment is preconfigured for WordPress security, reducing the manual effort required to implement server-level protections.
Shared Hosting vs. Managed WordPress Hosting for Security
Shared hosting places multiple websites on a single server. If one site on that server is compromised, attackers can sometimes move laterally to adjacent sites through shared file systems or misconfigured permissions. This risk is called cross-site contamination.
Managed WordPress hosting uses isolated environments for each site, reducing the risk of one site’s compromise spreading to others. Combined with ongoing monitoring, managed hosting removes the most common infrastructure-level risk from your security equation. For businesses handling sensitive customer data or running ecommerce stores, managed WordPress hosting is the appropriate hosting type.
WordPress Hosting Security Best Practices: Server-Level Hardening
WordPress hosting security best practices at the server level include keeping server software updated, configuring correct file permissions, disabling dangerous PHP functions, and enforcing HTTPS across all connections.
Keep PHP and Server Software Current
PHP version currency is one of the most overlooked server-level security controls. Each PHP version receives active security patches for a defined support window. Running an end-of-life PHP version means known vulnerabilities will never be patched by the PHP project. As of 2025, PHP 8.1 and earlier have reached or are approaching end-of-life status.
Your hosting provider should automatically maintain the server operating system, web server software (Apache or Nginx), and MySQL/MariaDB version. If your host requires you to manually request server software updates, that is a significant operational risk.
Configure Correct File Permissions
File permissions define who can read, write, and execute files on your server. Incorrect permissions are a common vector for attackers who have already gained partial access to a system.
Follow these permission standards for WordPress:
- wp-config.php: 400 or 440 (owner read-only)
- WordPress directories: 755 (owner can write, others read and execute)
- WordPress files: 644 (owner can write, others read-only)
- .htaccess: 644
Never set any WordPress file or directory to 777 (world-writable). A 777 permission allows any process on the server to write to that file, including malicious scripts.
Enforce HTTPS with a Valid SSL Certificate
HTTPS encrypts all data transmitted between your server and your visitors’ browsers. Without HTTPS, login credentials, form submissions, and payment data travel in plaintext that can be intercepted. Google has marked HTTP sites as “Not Secure” in Chrome since 2018, and HTTPS is a confirmed ranking factor.
Most quality hosting providers include a free SSL certificate via Let’s Encrypt. After installation, enforce HTTPS sitewide by:
- Redirecting all HTTP traffic to HTTPS via your .htaccess file or server configuration
- Setting your WordPress Site URL and Home URL to the https:// version in Settings > General
- Scanning for mixed content (HTTP resources loading on HTTPS pages) using a tool like the SSL Checker from SSL Labs
Disable PHP Execution in Writable Directories
Attackers who successfully upload a malicious PHP file to a writable directory can execute that file through the browser, gaining server access. Preventing PHP execution in directories like /wp-content/uploads/ removes this attack vector entirely.
Add the following to an .htaccess file inside your /wp-content/uploads/ directory:
<Files *.php>
deny from all
</Files>This directive tells the server to deny direct access to any PHP file in the uploads directory, regardless of how it got there.
Disable XML-RPC if Not Required
XML-RPC is a WordPress API that allows remote applications to interact with your site. It is a common target for brute force amplification attacks, where one XML-RPC request can attempt hundreds of password combinations simultaneously. If you do not use the WordPress mobile app, Jetpack, or any service requiring XML-RPC, disable it.
Add this to your .htaccess file:
<Files xmlrpc.php>
Order Deny,Allow
Deny from all
</Files>How to Secure Your WordPress Login Page
Securing the WordPress login page requires limiting brute force attempts, enabling two-factor authentication, changing the default login URL, and enforcing strong password policies across all user accounts.
Quick Answer: The WordPress login page is one of the most targeted attack surfaces. Wordfence blocked 55 billion password attack attempts in 2024 alone. Effective login protection combines login attempt limits, two-factor authentication, a non-default login URL, and strong unique passwords for every account, including editor and contributor roles.
Limit Login Attempts
WordPress allows unlimited login attempts by default. Brute force scripts exploit this by testing thousands of username and password combinations automatically. Limiting failed login attempts stops this attack at the source.
Use a plugin such as Limit Login Attempts Reloaded to:
- Allow a maximum of 3 failed attempts before a temporary lockout
- Set lockout duration to 15 minutes for first offense, 24 hours for repeat offenses
- Notify the administrator by email when lockout thresholds are exceeded
Enable Two-Factor Authentication (2FA)
Two-factor authentication requires a second verification step beyond the password. Even if an attacker obtains a valid password, 2FA prevents access without the second factor. Implement 2FA using a time-based one-time password (TOTP) app such as Google Authenticator or Authy.
Apply 2FA requirements to all user roles that have write access or higher. A compromised Contributor account may seem low-risk, but it can be used to inject malicious content or escalate privileges.
Change the Default Login URL
The default WordPress login URL is /wp-admin or /wp-login.php. Every automated attack script knows these paths and targets them first. Changing the login URL to a non-obvious path reduces automated attack volume significantly. Use a plugin like WPS Hide Login to set a custom path.
Rename the Default Admin Username
The username “admin” is the first credential attempted in every brute force script. WordPress no longer creates an “admin” account by default, but many older installations still use it. To change it:
- Create a new user with Administrator role and a unique username
- Transfer all content authored by the old account to the new one
- Delete the original “admin” account
Enforce Strong Password Policies
Weak passwords remain responsible for a significant share of WordPress compromises. Enforce these requirements for all accounts:
- Minimum 14 characters
- Mix of uppercase letters, lowercase letters, numbers, and symbols
- No dictionary words or predictable patterns
- Unique password not reused from any other service
- Password rotation every 90 days for administrator accounts
Use a password manager to generate and store complex credentials. WordPress includes a built-in password strength indicator during account creation.
Plugin and Theme Security Management
Plugin and theme security management involves auditing installed extensions regularly, removing unused or abandoned plugins, installing only from verified sources, and applying updates within 24 hours of release.
Quick Answer: Plugins account for 91% of WordPress vulnerabilities discovered in 2025, according to Patchstack. Every installed plugin is an additional attack surface. Keeping plugins minimal, updated, and sourced only from the official WordPress.org repository or verified commercial developers is the single most impactful action most WordPress site owners can take.
Audit Your Plugin Library Regularly
Conduct a plugin audit every 90 days:
- List all installed plugins and their last update date
- Remove any plugin not actively used or not updated in the past 12 months
- Research any plugin flagged in vulnerability databases (WPScan, Patchstack, Wordfence)
- Replace abandoned plugins with actively maintained alternatives
In 2024, 1,614 plugins were removed from the official WordPress.org repository due to security concerns. Plugins removed from the repository no longer receive updates, but they remain active on sites that never removed them.
Enable Automatic Updates for Plugins and Themes
Patchstack research shows that exploits targeting newly disclosed WordPress plugin vulnerabilities launch within 5 hours of public disclosure. Manual update workflows cannot match that response speed. Enable automatic updates for:
- WordPress core (minor versions and security releases)
- All plugins from reputable developers
- All active themes
For mission-critical custom plugins or themes, use a staging environment to validate automatic updates before they reach production. The staging-first approach prevents an update from breaking your live site while still maintaining rapid security patch application.
Only Install Plugins from Verified Sources
Never install nulled or pirated themes and plugins. Nulled software is commercial code distributed without a license, typically through unauthorized websites. These files almost always contain backdoors, malware injectors, or credential-harvesting scripts inserted by the distributor. The security cost of nulled software is always greater than the license fee avoided.
Install plugins only from:
- The official WordPress.org plugin repository
- Established commercial developers with active support
- Your own in-house development team
Remove Inactive Plugins and Themes
Deactivated plugins and themes still exist as files on your server. If those files contain vulnerabilities, attackers can exploit them even when the plugin is not active. Delete any plugin or theme you are not actively using. WordPress core comes with default themes bundled; delete all unused bundled themes except one for fallback purposes.
WordPress Database Security
WordPress database security requires using a custom database table prefix, restricting database user permissions, and backing up the database on a regular schedule to a remote location.
Change the Default Database Table Prefix
WordPress uses the wp_ prefix for all database tables by default. SQL injection attacks targeting WordPress often include this prefix in malicious queries. Changing the prefix to a custom value like pt47x_ makes injection attacks less effective. This change is easiest to implement during initial WordPress installation by modifying the $table_prefix variable in wp-config.php.
Restrict Database User Permissions
The WordPress database user requires only SELECT, INSERT, UPDATE, and DELETE permissions for normal operation. Grant only the minimum permissions required. Remove CREATE, DROP, ALTER, and GRANT permissions from the WordPress database user entirely unless you are performing a specific operation that requires them.
Secure wp-config.php
The wp-config.php file contains your database credentials, authentication keys, and salts. Protect it with:
- File permissions set to 400 or 440
- Moving the file one directory above the WordPress root (WordPress will still find it automatically)
- Blocking direct access via .htaccess
Add the following to your main .htaccess to block direct access:
<files wp-config.php>
order allow,deny
deny from all
</files>How to Implement a WordPress Backup Strategy
A WordPress backup strategy that meets security requirements includes automated backups stored in at least two geographically separate off-site locations, with tested restoration procedures verified at least once per quarter.
Quick Answer: A backup is your only guaranteed recovery option after a successful attack. Automated backups stored off-site (not on the same server as your WordPress installation) protect against malware, accidental deletion, and server failure. A backup stored only on the same server as the site it protects is not a true backup, as server-level compromises can corrupt or delete both simultaneously.
Backup Components to Include
A complete WordPress backup includes four components:
- Database: All post content, user data, settings, and plugin configurations
- WordPress core files: /wp-admin/ and /wp-includes/ directories
- Themes and plugins: /wp-content/themes/ and /wp-content/plugins/ directories
- Uploaded media: /wp-content/uploads/ directory
Backup Storage Locations
Store backups in at least two locations:
- Cloud storage: Google Drive, Amazon S3, or Dropbox
- Local storage: Your own computer or a local NAS device
Never rely solely on your hosting provider’s backup system. If your host’s infrastructure is compromised, their backups may be affected as well.
Test Your Backups
A backup that cannot be restored is not a backup. Test your restoration process at least once per quarter using a staging environment. Verify that:
- The site loads correctly after restoration
- All posts and pages are present
- Plugin settings are intact
- User accounts are accessible
Our WordPress hosting plans include automated backups with off-site storage, eliminating the need to configure and monitor backup plugins manually. Backup testing and restoration support are available from our team.
Security Plugins and Web Application Firewalls
Security plugins and web application firewalls (WAFs) provide an additional detection and blocking layer within your WordPress application, complementing the server-level protections your hosting provider should already have in place.
What a WordPress Security Plugin Does
A reputable WordPress security plugin provides:
- Malware scanning: Compares core files against known-good checksums and flags modifications
- Login protection: Enforces lockouts, 2FA, and CAPTCHA at the login page
- Firewall rules: Blocks requests matching known attack signatures before they reach WordPress
- File integrity monitoring: Alerts you when core WordPress files are modified unexpectedly
- Vulnerability alerts: Notifies you when an installed plugin or theme has a known vulnerability
Widely used security plugins include Wordfence and Sucuri Security. Each has a free tier that covers core scanning and firewall functionality.
Web Application Firewall Configuration
A WAF inspects incoming HTTP requests and blocks those matching known attack patterns such as SQL injection, cross-site scripting (XSS), and file inclusion attempts. XSS accounted for 47.7% of all WordPress vulnerabilities in 2025, making WAF coverage of this attack class particularly important.
Configure your WAF to:
- Block traffic from known malicious IP ranges
- Rate-limit requests to the login page
- Block access to sensitive files like wp-config.php and .htaccess
- Log all blocked requests for review
Some hosts provide a WAF at the server level, which is more efficient than an application-level WAF plugin because it blocks malicious traffic before it consumes server resources.
User Role Management and Access Control
User role management in WordPress requires applying the principle of least privilege, meaning every user account has only the permissions required to perform its specific function, and no more.
WordPress User Roles and Their Risk Levels
| Role | Default Capabilities | Security Risk if Compromised |
| Administrator | Full site control, plugin/theme management | Critical, full site takeover |
| Editor | Publish and manage all posts | High, can inject malicious content |
| Author | Publish and manage own posts | Medium |
| Contributor | Write posts, cannot publish | Low to medium |
| Subscriber | Read-only | Low |
Limit Administrator accounts to the minimum number of people who genuinely require full site access. For development agencies or teams managing a client’s site, create a dedicated Administrator account for ongoing work rather than using the site owner’s personal credentials.
Implement User Activity Logging
An activity log records every significant action taken in your WordPress dashboard: user logins, post edits, plugin activations, setting changes, and file modifications. When a security incident occurs, an activity log helps you identify which account was compromised, when access occurred, and what was changed. Many WordPress administrators do not use an activity log, leaving them without a forensic record when incidents occur, leaving the majority without a forensic record.
Use a plugin like WP Activity Log to maintain a complete audit trail of all WordPress dashboard activity.
Advanced WordPress Security Hardening
Advanced WordPress security hardening includes disabling file editing from the dashboard, blocking directory browsing, removing version number disclosure, and implementing Content Security Policy headers.
Disable the WordPress Theme and Plugin Editor
The WordPress dashboard includes a built-in code editor for themes and plugins accessible at Appearance > Theme File Editor. If an attacker gains admin access, this editor allows immediate code injection into any active theme or plugin file. Disable it by adding this line to wp-config.php:
define( 'DISALLOW_FILE_EDIT', true );Disable Directory Browsing
Directory browsing allows anyone to view the contents of a directory by typing its URL directly into a browser. This exposes your plugin and theme names, file structure, and potentially sensitive file names. Disable it by adding this to your .htaccess:
Options -Indexes
Remove WordPress Version Number from Source
WordPress displays its version number in the HTML source code of every page by default, in a <meta name=”generator”> tag. This tells attackers exactly which version of WordPress you are running, helping them target version-specific vulnerabilities. Remove it by adding this to your theme’s functions.php:
remove_action( 'wp_head', 'wp_generator' );Implement Security Headers
HTTP security headers instruct browsers on how to handle content, reducing the effectiveness of XSS attacks, clickjacking, and content injection. Add these headers via your .htaccess or server configuration:
- X-Content-Type-Options: nosniff – Prevents MIME-type sniffing
- X-Frame-Options: SAMEORIGIN – Prevents clickjacking
- X-XSS-Protection: 1; mode=block – Enables browser XSS filtering
- Referrer-Policy: strict-origin-when-cross-origin – Controls referrer header data
WordPress Security Monitoring and Incident Response
WordPress security monitoring requires setting up automated alerts for unusual activity, establishing a defined incident response process, and knowing what to do immediately when a compromise is detected.
Quick Answer: Security monitoring converts reactive breach response into proactive threat detection. Without monitoring, compromised WordPress sites can go undetected for weeks or months, giving attackers extended access to your data and infrastructure. Real-time alerting on login anomalies, file changes, and malware detections dramatically reduces this exposure window.
Set Up Automated Security Alerts
Configure alerts for:
- Failed login attempts exceeding your threshold
- New Administrator account creation
- Core WordPress file modifications
- Plugin activation or deactivation
- Changes to critical settings (site URL, admin email)
- Malware scan detections
WordPress Incident Response Steps
If your site is compromised, follow this sequence:
- Take the site offline immediately to prevent further data exposure and stop malware distribution to visitors
- Notify your hosting provider so they can isolate your hosting environment and begin server-level investigation
- Change all passwords for WordPress admin accounts, FTP/SFTP, database, and cPanel or hosting control panel
- Restore from a clean backup made before the compromise occurred
- Identify the entry point by reviewing server access logs and WordPress activity logs
- Apply the necessary security patch or remove the vulnerable plugin or theme that allowed entry
- Run a full malware scan on the restored site to confirm it is clean
- Request Google Search Console reconsideration if your site was blacklisted during the incident
How Prestige Technologies Secures Your WordPress Hosting Environment
We build security into every layer of our managed WordPress hosting infrastructure. Site owners should not need to be server administrators to run a secure WordPress installation. Our approach removes the most complex security responsibilities from your plate.
The hosting environment includes server-level firewalls, DDoS mitigation, automatic malware scanning, and isolated hosting environments that prevent cross-site contamination. WordPress core and server-side software are kept current automatically. Automated backups with off-site storage are included as standard, with restoration support available from our team.
For businesses running our WooCommerce hosting or those with specific compliance requirements, we can tailor the security configuration to match the risk profile of your specific store or application. SSL certificates and WAF configuration are included.
Our team works as an extension of yours. When security events occur, you have expert support available to guide incident response, restore from backup, and identify the root cause. That level of partnership is what separates managed WordPress hosting from commodity shared hosting options.
For small and medium-sized businesses evaluating their hosting options, our SMB hosting plans are designed with the same professional-grade security foundation as our managed hosting, at a price point accessible to growing organizations.
WordPress Security Checklist: 30 Controls to Implement Today
Use this checklist to audit your current WordPress hosting security posture. Work through each item systematically, prioritizing items marked Critical.
Hosting and Server
- [ ] Host provides isolated or managed environments, not basic shared hosting (Critical)
- [ ] PHP version is current and actively supported (Critical)
- [ ] Server software (OS, web server, database) is automatically updated (Critical)
- [ ] Server-level WAF is active (Critical)
- [ ] SSL certificate is installed and HTTPS is enforced sitewide (Critical)
- [ ] DDoS protection is active at the network level (High)
- [ ] Staging environment is available for testing updates (High)
- [ ] Automated backups stored off-site (Critical)
WordPress Application
- [ ] WordPress core is on the latest version (Critical)
- [ ] All plugins are on their latest versions (Critical)
- [ ] All themes are on their latest versions (High)
- [ ] Unused plugins are deleted, not just deactivated (High)
- [ ] Unused themes are deleted (Medium)
- [ ] Only plugins from verified sources are installed (Critical)
- [ ] No nulled themes or plugins are installed (Critical)
- [ ] DISALLOW_FILE_EDIT is set to true in wp-config.php (High)
- [ ] Directory browsing is disabled (High)
- [ ] WordPress version number is removed from HTML source (Medium)
- [ ] XML-RPC is disabled if not required (High)
- [ ] PHP execution is blocked in /wp-content/uploads/ (High)
Login and Access Control
- [ ] Default “admin” username has been changed (Critical)
- [ ] All admin accounts use unique, strong passwords of 14+ characters (Critical)
- [ ] Two-factor authentication is enabled for all admin accounts (Critical)
- [ ] Login attempt limits are configured (Critical)
- [ ] Default login URL has been changed (High)
- [ ] CAPTCHA is implemented on the login and registration forms (High)
- [ ] User roles follow principle of least privilege (High)
- [ ] WordPress activity logging is active (High)
Database
- [ ] Database table prefix has been changed from wp_ (Medium)
- [ ] wp-config.php file permissions are set to 400 or 440 (Critical)
Conclusion
WordPress hosting security best practices are not a one-time configuration task. They are an ongoing commitment to maintaining the layers of protection that stand between your site and the thousands of automated attacks targeting WordPress installations every day. The data is clear: 7,966 new vulnerabilities were discovered in 2024, exploits launch within 5 hours of disclosure, and nearly half of all vulnerable plugin installations never receive a patch from their developer.
The most effective approach to WordPress security combines a hosting provider that handles server-level protections automatically with your own diligence at the application and user-behavior layers. When your host manages the infrastructure, you can focus on keeping plugins current, managing user access correctly, and maintaining tested backups.
We provide managed WordPress hosting built around this philosophy. From server-level firewalls and automatic malware scanning to automated off-site backups and expert incident response support, the security foundation is already in place. Explore our managed WordPress hosting plans and take the infrastructure security burden off your team today.
Frequently Asked Questions
1. What are the most important WordPress hosting security best practices for a small business? The most important WordPress hosting security best practices for a small business are: choosing a managed host with built-in server-level protections, enabling two-factor authentication on all administrator accounts, keeping all plugins and themes updated within 24 hours of release, maintaining off-site backups, and installing a reputable security plugin. These five measures address the majority of common attack vectors targeting WordPress small business sites.
2. How often is WordPress hacked? WordPress sites face automated attack attempts at a rate of approximately one attack every 32 minutes in 2025, down from one every 22 minutes in 2024, according to Hostinger’s analysis of industry security data. However, successful compromises remain common. Sucuri tracked over 500,000 infected WordPress websites in 2024. The frequency of attacks means that unprotected sites face near-constant automated probing.
3. Why is WordPress so vulnerable to security threats? WordPress is not inherently insecure, but its 43.5% market share makes it an attractive target for attackers who can build automated scripts that exploit vulnerabilities across millions of sites simultaneously. The open-source ecosystem means third-party developers produce plugins and themes of varying security quality. Plugins account for 91% of WordPress vulnerabilities. WordPress core itself recorded only 6 vulnerabilities in 2025, according to Patchstack.
4. What is the best WordPress security plugin? The best WordPress security plugins are Wordfence Security and Sucuri Security, both of which provide malware scanning, web application firewall functionality, login protection, and file integrity monitoring. Wordfence is the most widely deployed, with a strong free tier. Sucuri provides additional cloud-based WAF protection. The best choice depends on your budget, technical comfort level, and specific threat profile.
5. How do I keep a WordPress site secure? Keeping a WordPress site secure requires a layered approach: use a managed hosting provider with server-level protections, keep WordPress core and all plugins and themes updated, enforce strong passwords and 2FA on all user accounts, limit login attempts, maintain regular off-site backups, run regular malware scans, and audit user roles and installed plugins every 90 days. No single action provides complete security on its own.
6. What are common WordPress security vulnerabilities and how do I prevent them? Common WordPress security vulnerabilities include cross-site scripting (XSS), accounting for 47.7% of all flaws in 2025, SQL injection, brute force attacks on the login page, outdated plugin exploits, and malicious file uploads. Prevent them by using a WAF, limiting login attempts, enabling 2FA, keeping all software updated, blocking PHP execution in the uploads directory, and validating all user input in custom code.
7. Is WordPress good for security? WordPress core is very secure. Patchstack identified only 6 WordPress core vulnerabilities in 2025. The security risk in WordPress comes primarily from third-party plugins, which account for 91% of all vulnerabilities. A WordPress site running minimal, well-vetted, and consistently updated plugins with proper server-level protections is as secure as any other CMS platform.
8. Why is my WordPress site showing as “not secure”? A WordPress site shows as “Not Secure” in browsers when it is not using HTTPS. This means either an SSL certificate has not been installed, the certificate has expired, or the site is loading some resources (images, scripts, or stylesheets) over HTTP even though the main site uses HTTPS (a condition called mixed content). Install or renew an SSL certificate and enforce HTTPS sitewide, then use a tool like the SSL Labs SSL Test to identify any remaining mixed content issues.
9. How do I password protect an entire WordPress site? You can password protect an entire WordPress site using HTTP authentication at the server level via .htaccess and .htpasswd files, or by using a plugin like Password Protected to require a password before any content is displayed. HTTP authentication is the more secure option as it operates before WordPress even loads. This approach is often used for staging sites that should not be publicly accessible before launch.
10. What is two-factor authentication and why does WordPress need it? Two-factor authentication (2FA) requires a second verification step beyond the password, typically a time-limited code generated by an authenticator app. WordPress needs 2FA because Wordfence blocked 55 billion password attack attempts against WordPress sites in 2024. Even when a password is stolen through phishing or data breach exposure, 2FA prevents the stolen credential from being used to access the account without the second factor.
11. How do I secure wp-config.php? Secure wp-config.php by setting file permissions to 400 or 440 to allow only the file owner to read it, blocking direct HTTP access through an .htaccess directive, moving the file one directory above the WordPress root directory (WordPress will locate it automatically), and ensuring the file contains strong, randomly generated authentication keys and salts. Replace default salts using the WordPress Secret Key Generator available at api.wordpress.org/secret-key/1.1/salt/.
12. What does a web application firewall (WAF) do for WordPress? A web application firewall (WAF) inspects all incoming HTTP requests before they reach your WordPress application and blocks requests matching known attack signatures, including SQL injection attempts, XSS payloads, malicious file upload requests, and brute force login patterns. A WAF operating at the server or CDN level is more efficient than an application-level firewall plugin because it stops malicious traffic before it consumes server resources.
13. How do I remove malware from a WordPress site? Remove malware from a WordPress site by first taking the site offline to stop further harm, then restoring from a clean pre-infection backup if one is available. If no clean backup exists, use a malware scanner to identify infected files, delete or replace them with clean versions downloaded from WordPress.org, change all passwords and revoke all active sessions, identify the vulnerability that allowed the infection, and apply the relevant security patch or remove the vulnerable component.
14. What file permissions should WordPress use? WordPress file permissions should be 644 for all files and 755 for all directories. The wp-config.php file should use 400 or 440 for maximum protection. The .htaccess file should use 644. Never use 777 permissions on any WordPress file or directory, as this makes the file writable by any process on the server, including malicious scripts and automated attack tools.
15. How often should I back up my WordPress site? WordPress sites with daily content updates should be backed up daily. Sites with less frequent content changes should be backed up at minimum weekly. Backups should be stored in at least two separate off-site locations. Database backups are the highest priority because they contain all post content, user data, and settings. Test your restoration procedure at least once per quarter to confirm backups are recoverable.
16. What is the downside of WordPress regarding security? The main security downside of WordPress is the vast third-party plugin and theme ecosystem, where quality and maintenance standards vary widely. In 2024, 1,614 plugins were removed from the WordPress.org repository due to security issues. Many of these remained installed and active on thousands of sites after removal. The popularity of WordPress also means attackers invest heavily in discovering and exploiting WordPress-specific vulnerabilities, producing a high volume of targeted attack tools.
17. How do I limit login attempts in WordPress? Limit login attempts in WordPress by installing a plugin such as Limit Login Attempts Reloaded or WP Cerber Security. Configure the plugin to allow no more than 3 failed attempts before triggering a lockout, set initial lockout duration to 15 minutes, and escalate repeat offenders to a 24-hour lockout. Enable email notifications to the site administrator when lockout thresholds are reached. Also change the default login URL to reduce the volume of automated attacks reaching the login form.
18. What happens when a WordPress plugin is removed from the repository? When a WordPress plugin is removed from the WordPress.org repository, it stops receiving updates through the WordPress dashboard. Site owners with the plugin installed do not receive automatic notification of the removal. The plugin continues running on the site, potentially with unpatched vulnerabilities. Check the status of all installed plugins regularly by searching their names in the WordPress.org plugin repository. If a plugin has been removed, delete it and find an actively maintained alternative.
19. How do I prevent SQL injection attacks on WordPress? Prevent SQL injection attacks on WordPress by keeping all plugins and themes updated (most SQL injection vulnerabilities exist in third-party code), using a WAF configured to detect and block SQL injection patterns, changing the default database table prefix from wp_ to a custom value, restricting database user permissions to only those required for WordPress operation, and never using nulled plugins or themes that may contain deliberately injected malicious SQL code.
20. What is the difference between WordPress security and WordPress hosting security? WordPress security refers to practices applied at the application layer: plugin management, user roles, login protection, and WordPress-specific configurations. WordPress hosting security refers to protections applied at the server and infrastructure layer: server software currency, network-level firewalls, DDoS mitigation, isolated hosting environments, server-side malware scanning, and data center physical security. Both layers are required. Application-layer security cannot compensate for server-level weaknesses, and server-level security cannot protect against vulnerable or malicious plugin code running inside WordPress.