---
title: "WordPress .htaccess Security: What Actually Helps"
canonical: https://wpsecurityninja.com/wordpress-htaccess-security/
---
`.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.

![WordPress .htaccess Security](https://wpsecurityninja.com/media/2025/04/WordPress-.htaccess-Security.webp)

## 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.

**Managed WordPress hosts** (Kinsta, WP Engine, Flywheel-style stacks, and similar) often block or ignore custom `.htaccess` edits for security. You may only get HTTPS forcing, redirects, or IP rules through the host panel. Ask support before you assume Apache snippets will apply.

**OpenLiteSpeed / hybrid stacks** may parse different directive syntax. A rule that works on classic Apache 2.4 can 500 on another layer.

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.

## When `.htaccess` is the wrong tool

| Situation | Better approach |
| --- | --- |
| Nginx or managed host without Apache overrides | Host panel, server block, or CDN rules |
| Blocking exploit-shaped requests at scale | [Cloud Firewall](https://wpsecurityninja.com/cloud-firewall/) or CDN WAF |
| Login brute force | [Login protection](https://wpsecurityninja.com/login-protection/) instead of IP-only wp-login blocks |
| Malware already on disk | Cleanup and scans; `.htaccess` does not delete infected PHP |
| PHP upload limits | Host `php.ini` or panel, not always `php_value` in `.htaccess` |

Hand-written rules complement a maintained firewall. They do not replace updates or login hardening.

## 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
# Apache 2.4+
<Files "wp-config.php">
  Require all denied
</Files>
```

```apache
# 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`

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

### 2. Disable directory listing

```apache
Options -Indexes
```

### 3. Disable PHP execution in uploads

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

```apache
<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:

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

Prefer firewall rate limits when you must keep XML-RPC. See [login security](https://wpsecurityninja.com/wordpress-login-security-complete-guide/).

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

```apache
<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:

```apache
<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](https://wpsecurityninja.com/login-protection/) covers that without IP pinning.

### 7. Optional: block author enumeration probes

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

### 8. Optional: reduce image hotlinking

```apache
<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](https://wpsecurityninja.com/wordpress-firewall-plugins-guide/) 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](https://wpsecurityninja.com/wordpress-security-hardening-guide/), [login security](https://wpsecurityninja.com/wordpress-login-security-complete-guide/), and a real [firewall](https://wpsecurityninja.com/wordpress-firewall-plugins-guide/).

## Plugin firewall vs hand-written rules

Security Ninja Pro’s [Cloud Firewall](https://wpsecurityninja.com/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](https://wpsecurityninja.com/security-plugin-setup-guide/). Conflict advice: [plugin conflicts](https://wpsecurityninja.com/security-plugin-conflicts-resolution/).

## 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 .htaccess generator](https://wpsecurityninja.com/tools/htaccess/)
- [WordPress security hardening guide](https://wpsecurityninja.com/wordpress-security-hardening-guide/)
- [WordPress firewall plugins guide](https://wpsecurityninja.com/wordpress-firewall-plugins-guide/)
- [WordPress security checklist](https://wpsecurityninja.com/wordpress-security-checklist/)
- [Security plugin setup](https://wpsecurityninja.com/security-plugin-setup-guide/)
- [Firewall docs](https://wpsecurityninja.com/docs/firewall/)

## 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](https://wordpress.org/plugins/security-ninja/) or see [pricing](https://wpsecurityninja.com/pricing/) for Pro.