Background Gradient for Hero Section

How to Harden WordPress Without a Plugin

WordPress powers over 43% of the web, making it a massive target for hackers and bots. While security plugins are a popular choice to defend against threats, relying solely on them isn’t the most robust or professional strategy. For developers, agencies, and freelancers who want to tighten WordPress security at the foundational level, it’s essential to know how to harden WordPress without a plugin.

In this guide, we’ll walk through practical, code-based techniques to secure your WordPress site without bloating it with unnecessary plugins. These strategies reduce attack surfaces, prevent exploitation of known vectors, and strengthen your site’s defenses.

11 ways to harden WordPress Security

Securing your WordPress site doesn’t always require installing a plugin. In fact, some of the most effective hardening strategies come from server-level configurations and native WordPress features. From disabling file editing and XML-RPC to enforcing strong user permissions, these 11 methods are straightforward, lightweight, and reduce your attack surface significantly. Each one adds a layer of defense, helping you build a site that’s resilient against brute-force attacks, code injections, and unauthorized access — all without bloating your site with extra plugins.

Disable File Editing from the Admin Dashboard

WordPress allows administrators to edit theme and plugin files directly via the dashboard (Appearance > Theme Editor and Plugins > Plugin Editor). While convenient, this is a major security risk if an attacker gains admin access.

To disable it, add the following to your wp-config.php:

define('DISALLOW_FILE_EDIT', true);

This small change can prevent malicious code injections through the admin area.

Restrict Access to wp-config.php and .htaccess

Your wp-config.php and .htaccess files hold critical configuration and security settings. Lock them down at the server level using .htaccess rules (Apache):

<Files wp-config.php>
  Order allow,deny
  Deny from all
</Files>

<Files .htaccess>
  Order allow,deny
  Deny from all
</Files>

For NGINX, use:

location ~* wp-config.php {
    deny all;
}

Disable XML-RPC

The XML-RPC endpoint (xmlrpc.php) is a common attack vector used for brute-force attacks and pingback spam. If you don’t use Jetpack or remote publishing, disable it.

Apache users can block access via .htaccess:

<Files xmlrpc.php>
  Order Deny,Allow
  Deny from all
</Files>

Or disable it in theme’s functions.php:

add_filter('xmlrpc_enabled', '__return_false');

Move the wp-config.php file to the root

WordPress allows wp-config.php to reside outside the root directory. Moving it one level up adds an extra layer of protection:

  • Default path: /public_html/wp-config.php
  • Move it to: /wp-config.php

WordPress will still detect it.

Disable Directory Browsing

Directory browsing can expose sensitive file structure and configuration files.

To disable, add this line to .htaccess:

Options -Indexes

This prevents browsers from listing directory contents.

Implement Strong File Permissions

Improper permissions can leave your site vulnerable to unauthorized changes. Set permissions correctly:

  • wp-config.php: 400 or 440
  • .htaccess: 404
  • Files: 644
  • Directories: 755

You can use the following shell command recursively:

find . -type d -exec chmod 755 {} \;
find . -type f -exec chmod 644 {} \;

Change Default Database Prefix

WordPress defaults to using wp_ as the database table prefix. Attackers often target this in SQL injection attempts. During installation or via a migration process, change it to something unique like mywp_.

If you’ve already installed WordPress:

  • Backup the database
  • Rename all tables
  • Update wp-config.php
  • Update any hardcoded queries or plugins that use table names

Disable PHP Execution in Uploads Directory

Attackers often exploit file uploads to inject PHP backdoors. Prevent execution of PHP in the /wp-content/uploads folder:

Create a .htaccess file inside /uploads/ with:

<Files *.php>
  deny from all
</Files>

Or use NGINX:

location ~* /uploads/.*\.php$ {
    deny all;
}

Secure wp-admin with HTTP Authentication

Adding a second layer of password protection to /wp-admin using .htpasswd is an effective brute-force deterrent.

Steps:

  1. Generate a .htpasswd file using a tool like htpasswd
  2. Add this to your .htaccess inside /wp-admin/:
AuthType Basic
AuthName "Restricted Area"
AuthUserFile /path/to/.htpasswd
Require valid-user

Limit Login Attempts (Without a Plugin)

While plugins like Limit Login Attempts Reloaded do this well, you can also use server-level tools:

For Apache (via .htaccess + Fail2Ban):

  • Monitor POST requests to wp-login.php
  • Use IP banning based on failed attempts

For NGINX, you can rate-limit login attempts:

limit_req_zone $binary_remote_addr zone=login:10m rate=1r/m;

location = /wp-login.php {
    limit_req zone=login burst=2;
    include fastcgi_params;
}

Use a Read-Only File System (for Advanced Setups)

If you’re running on a VPS or containerized environment, consider making parts of your file system read-only:

  • /wp-content/plugins
  • /wp-content/themes

This prevents modification even if the admin is compromised. Mount these directories as read-only and update them manually when needed.

Frequently Asked Questions

Is hardening WordPress without a plugin enough for security?

For many sites, yes, especially if you follow best practices at the server and code level. However, monitoring and firewall services still add value, especially for high-traffic or enterprise sites.

Will disabling XML-RPC break anything?

If you’re not using Jetpack, pingbacks, or remote publishing, it’s safe to disable. Always test your setup before deployment.

What’s the best way to track login attempts without a plugin?

Use server logs, Fail2Ban, or custom hooks in wp_login_failed to track and limit logins. For large sites, consider central logging with tools like Logstash or Graylog.

Can I apply these methods on shared hosting?

Many, yes, especially .htaccess-based ones. For advanced techniques (like read-only FS or NGINX config), you’ll need server access.

Should I still use a security plugin if I do all this?

You can, but focus on minimal, well-coded tools that don’t add unnecessary features. Your goal is layered security, these methods give you the first (and strongest) layer.

Conclusion

Securing your WordPress installation doesn’t have to rely on third-party plugins. In fact, understanding how to harden WordPress at the server and configuration level puts you in full control and often results in better performance and fewer vulnerabilities.

These techniques give you surgical-level protection without adding plugin bloat or new attack surfaces. Use them in every client build, especially on high-value or sensitive projects. Better yet, automate many of these through your deployment scripts or Docker images.

Security isn’t one-and-done, it’s a mindset. And mastering these non-plugin methods positions you as a WordPress professional who truly understands how to build secure, scalable sites.

Mehul Gohil
Mehul Gohil

Mehul Gohil is a Full Stack WordPress developer and an active member of the local WordPress community. For the last 13+ years, he has been developing custom WordPress plugins, custom WordPress themes, third-party API integrations, performance optimization, and custom WordPress websites tailored to the client's business needs and goals.

Articles: 164

Leave a Reply

Your email address will not be published. Required fields are marked *

Discover more from Mehul Gohil

Subscribe now to keep reading and get access to the full archive.

Continue reading