WordPress .htaccess Security: What Actually Helps

.htaccess is an Apache config file that can block paths, force HTTPS, and tighten directory access. It is useful on Apache hosts. It is easy to break a site with a bad rule. It is not a substitute for updates, strong logins, or malware cleanup.

Prerequisites (read this first)

• Your host runs Apache, or LiteSpeed with Apache-compatible .htaccess support
• You can edit files over SFTP, SSH, or the host file manager
• You have a backup of the current .htaccess (download a copy before every change)
• You can restore that file quickly if the site returns 500 errors

Nginx-only hosts ignore .htaccess. Equivalent rules belong in the server block or a host panel. Do not paste these snippets on Nginx and expect them to work.

LiteSpeed often honors many Apache rules, but syntax and modules still differ. Change one rule at a time and test.

WordPress also writes its own rewrite block into .htaccess for pretty permalinks. Keep the # BEGIN WordPress / # END WordPress block intact unless you know why you are changing it.

Safe workflow

1. Backup files and database
2. Download the current root .htaccess
3. Add one rule (or one small block)
4. Load the homepage, a post, and /wp-admin/
5. If anything breaks, restore the backup file immediately via SFTP or the host file manager
6. Only then add the next rule

Never edit .htaccess in Word or a rich-text editor. Use a plain-text editor.

Apache 2.2 vs 2.4 access control

Older tutorials use Order allow,deny / Deny from all. Apache 2.4 prefers Require:

# Apache 2.4+
<Files "wp-config.php">
  Require all denied
</Files>

# Legacy Apache 2.2 style (some hosts still accept this)
<Files wp-config.php>
  Order allow,deny
  Deny from all
</Files>

If a 2.2-style rule 500s on your host, switch to the Require form. If you are unsure which Apache version you have, ask the host or check their docs.

High-value rules (keep them boring)

Place most of these in the site root .htaccess next to wp-config.php, unless a note says otherwise. Replace example IPs and domains with yours.

1. Protect wp-config.php

<Files "wp-config.php">
  Require all denied
</Files>

2. Disable directory listing

Options -Indexes

3. Disable PHP execution in uploads

Create (or edit) wp-content/uploads/.htaccess:

<FilesMatch "\.php$">
  Require all denied
</FilesMatch>

Test that normal image URLs still load. Some hosts already enforce this; duplicate rules are usually fine.

4. Block XML-RPC (only if you do not need it)

XML-RPC is used by some mobile apps, Jetpack-related flows, and remote publishing. Disable only when nothing you use needs it:

<Files "xmlrpc.php">
  Require all denied
</Files>

Prefer firewall rate limits when you must keep XML-RPC. See login security.

5. Force HTTPS (if the host panel does not)

<IfModule mod_rewrite.c>
  RewriteEngine On
  RewriteCond %{HTTPS} off
  RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
</IfModule>

Confirm the site already has a working certificate before forcing HTTPS.

6. Optional: limit wp-login.php by IP

Useful for a fixed office IP. Painful for travel, home ISP changes, and agencies:

<Files "wp-login.php">
  Require ip 203.0.113.10
</Files>

Whitelist every IP that must log in, or you will lock yourself out. Login rate limits in a plugin are usually safer for teams. Login protection covers that without IP pinning.

7. Optional: block author enumeration probes

<IfModule mod_rewrite.c>
  RewriteEngine On
  RewriteCond %{QUERY_STRING} author=\d [NC]
  RewriteRule ^ - [F]
</IfModule>

8. Optional: reduce image hotlinking

<IfModule mod_rewrite.c>
  RewriteEngine On
  RewriteCond %{HTTP_REFERER} !^$
  RewriteCond %{HTTP_REFERER} !^https?://(www\.)?example\.com [NC]
  RewriteRule \.(jpe?g|png|gif|webp)$ - [F,NC,L]
</IfModule>

Replace example.com with your domain. Hotlink blocking is bandwidth control more than malware defense.

Rules to treat carefully

• Broad “SQL injection” query-string filters often break real plugins, search URLs, and admin tools. Prefer a maintained firewall over a giant regex denylist.
• php_value upload limits only work when PHP runs as an Apache module. Many hosts ignore them or error. Set upload limits in the host panel or php.ini instead.
• Security headers (for example X-Frame-Options) are fine when mod_headers is enabled. A wrong header line can 500 the site; test after adding.

What .htaccess does not fix

• Vulnerable plugins still get exploited through allowed PHP endpoints
• Weak passwords still work on wp-login.php
• Malware already in themes or mu-plugins still runs
• Nginx sites ignore these files unless the host maps similar rules elsewhere

For those jobs, use hardening, login security, and a real firewall.

Plugin firewall vs hand-written rules

Security Ninja Pro’s Cloud Firewall blocks known bad IPs (600M+), filters abusive requests, and handles login/404 abuse without you maintaining a private rulebook. Hand-written .htaccess rules can complement that for host-specific file protection. They should not compete with it by duplicating WAF logic you do not understand.

Setup path: security plugin setup. Conflict advice: plugin conflicts.

If a rule locks you out

1. Connect with SFTP or the host file manager (not wp-admin)
2. Rename .htaccess to .htaccess.broken or restore your downloaded copy
3. Confirm the site loads
4. Re-add rules one at a time

Related reading

• WordPress security hardening guide
• WordPress firewall plugins guide
• WordPress security checklist
• Security plugin setup
• Firewall docs

Bottom line

.htaccess is a scalpel, not a full security stack. Use a few proven file and directory protections, keep a restore path, and put day-to-day blocking in a maintained firewall. Start Free on WordPress.org or see pricing for Pro.