WordPress Security Hardening: The Complete .htaccess & wp-config.php Guide for 2026

Why Server-Level Hardening Matters More Than Plugins

A fresh WordPress install is a wide-open target. Default configurations leave critical attack surfaces exposed: directory listings reveal your file structure, PHP files in the uploads folder can execute arbitrary code, XML-RPC endpoints accept brute-force login attempts at scale, and server response headers advertise your entire software stack to automated scanners.

Most WordPress security advice points you toward plugins. But security plugins run inside WordPress, which means they load after the PHP process starts, after the database connects, and after dozens of hooks fire. Server-level rules in .htaccess and compile-time constants in wp-config.php execute before WordPress even initializes. They block malicious requests at the gate, not in the living room.

This guide walks through every layer of server-level security you should configure on a production WordPress site. Each section includes the exact rules you need, explains what they protect against, and links to a FyrePress tool that generates the code for you automatically.

Protect wp-config.php from Direct Access

Your wp-config.php file contains your database credentials, authentication keys, table prefix, and debug settings. If a server misconfiguration ever causes PHP to stop processing (it happens more often than you think during updates), your config file could be served as plain text to any browser request.

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

This rule ensures that even if PHP fails, Apache will return a 403 Forbidden for any direct request to wp-config.php. WordPress itself accesses the file through PHP’s include() function, which bypasses Apache’s access rules entirely, so this does not break your site.

Disable Directory Browsing

Without explicit directory listing protection, visiting yourdomain.com/wp-content/uploads/ in a browser displays every file in the directory. Attackers use this to enumerate your plugin versions, theme structure, and uploaded file names. A single line stops it:

Options -Indexes

This directive tells Apache to return a 403 instead of rendering a directory listing when no index.html or index.php exists. It should be in every production .htaccess file without exception.

Block PHP Execution in the Uploads Directory

One of the most common WordPress attack patterns is uploading a PHP shell disguised as an image file. Even with proper file type validation, edge cases exist where a .php file can land in wp-content/uploads/. The fix is to prevent PHP execution entirely in that directory:

# In wp-content/uploads/.htaccess
<Files "*.php">
    Order Allow,Deny
    Deny from all
</Files>

Create a separate .htaccess file inside your wp-content/uploads/ directory with this rule. Even if a malicious PHP file makes it into the folder, Apache will refuse to execute it. This single rule has prevented more WordPress compromises than any security plugin.

Lock Down XML-RPC

WordPress’s xmlrpc.php endpoint was designed for remote publishing from desktop clients and mobile apps. Today, it’s primarily used as a brute-force amplification vector. A single XML-RPC request can test hundreds of username-password combinations via the system.multicall method, bypassing login rate limiting entirely.

If you do not use the WordPress mobile app, Jetpack, or any plugin that requires XML-RPC, block it completely at the server level:

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

Rotate Your Security Salts Regularly

WordPress uses eight cryptographic salt constants in wp-config.php to secure cookies, nonces, and password hashes. Most installations set these once during setup and never touch them again. The problem: if a salt is ever exposed (through a backup leak, a compromised developer machine, or a server log), every authenticated session on your site is vulnerable.

Rotating salts is simple and safe. Changing them instantly invalidates all existing login sessions, forcing every user (including any attacker with a stolen session cookie) to re-authenticate. You should rotate salts after any suspected breach, and ideally on a regular quarterly schedule.

Block Malicious Bots and Scanners

Automated vulnerability scanners like WPScan, Nikto, and SQLMap advertise themselves in their User-Agent strings. While sophisticated attackers spoof these headers, a significant portion of automated attacks still use default scanner signatures. Blocking known malicious User-Agents at the server level reduces noise in your access logs and stops low-effort attacks cold.

Beyond User-Agent filtering, you should also block direct access to WordPress-specific paths that are commonly probed: wp-admin/install.php, wp-admin/setup-config.php, and the readme.html file that reveals your WordPress version.

Add Security Headers via .htaccess

HTTP security headers tell the browser how to handle your content and are one of the most impactful security improvements you can make. The key headers every WordPress site should set:

• X-Content-Type-Options: nosniff — prevents browsers from MIME-sniffing a response away from the declared content type, blocking a class of XSS attacks.
• X-Frame-Options: SAMEORIGIN — prevents your site from being embedded in iframes on other domains, blocking clickjacking attacks.
• Referrer-Policy: strict-origin-when-cross-origin — controls how much referrer information is sent with requests, preventing data leakage.
• Permissions-Policy — controls which browser features (camera, microphone, geolocation) your site can access.
• Content-Security-Policy — the most powerful header, controls which sources of content the browser will execute. Requires careful configuration to avoid breaking functionality.

Hide the WordPress Version Number

WordPress exposes its version number in multiple locations: the <meta name="generator"> tag, RSS feed headers, script and stylesheet query strings, and the readme.html file. Attackers cross-reference your version against known vulnerability databases (WPVulnDB, CVE) to identify exploits that apply to your exact installation.

Hiding the version number is not security through obscurity — it is reducing the information available to automated scanners that triage targets by vulnerability count. Combined with the other measures in this guide, it raises the effort threshold significantly for opportunistic attacks.

Testing Your Configuration

After implementing these rules, verify each one individually. Do not deploy all security changes at once to a production server — a single misplaced directive can take your entire site offline.

Test on a staging environment first. If anything breaks, remove the most recently added rule and re-test. Each rule in this guide is independent, so you can safely deploy them incrementally.

Frequently Asked Questions