Server Security

Rewrite Rule Conflicts when Protecting Subdirectories Using .htaccess

Editor’s note: This article assume a level of knowledge that some readers may not yet have attained. If you have any questions, don’t hesitate to open a ticket in your customer portal.

Protecting directories using .htaccess is typically a straight-forward and painless process. Create a .htpasswd file, set up some authentication rules in .htaccess and you’re good to go!

But what happens when you want to password protect sub-directories on a site that uses a CMS such as WordPress, and all of a sudden, every time you try to access your password protected sub-directories, you get a 404 Error? Don’t worry, the solution to this problem is much easier than you may think.

CMS Rewrite Rules in .htaccess

Usually, CMSes rely heavily on rewrite rules to create “clean” URLs so that individual pages are easy to remember and are easily indexed by search engines. For example, instead of accessing a page with, the CMS will create the much more user friendly using rewrite rules.

Password protection and .htaccess conflicts

Rewrite rules are typically implemented in the .htaccess at the top level of the document root. If you have an .htaccess file in another lower directory, there can sometimes be a conflict.

Let’s say you want to password protect and you have a CMS installed at

In the .htaccess file located in the Document Root, there are rewrite rules that look something like this:

RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]

The code above tells Apache (the web server) that if the URL provided by the user does not reference the location of an actual file or directory, then it should rewrite the URL to the main index.php file. This passes that easy-to-remember URL back into the CMS, where it does its magic to serve the content you are looking for. Alternatively, you can configure the CMS to return a custom 404 error page if the content you are looking for cannot be found.

You have checked and made sure that the sub-directory you are looking for exists, so why do you still get the 404 error?

In a typical configuration, when the the web server tries to access the password protected directory, the web server responds with a “401 Unauthorized” header and an optional error document, then prompts the user for Authentication details. When rewrite rules are in place, the default error document path used by the web server is evaluated using the rewrite rules. If an actual error document does not exist in the default error document path, this is passed on to the CMS for parsing. In this case, since the file is not found, the CMS gets confused and displays a 404 error rather than a 401, causing the web server to not even prompt for authentication.

Fixing the 404 error and .htaccess rules conflict

To resolve this .htaccess rule conflict, you can override the default error document path by adding the “ErrorDocument” directive in the .htaccess file discussed above. Here is an example:

ErrorDocument 401 default
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]

In this example, we used:

ErrorDocument 401 default

This causes the web server to return its built-in default 401 error message.

There are several variations of the “ErrorDocument” directive that can be used, which are not covered here. For more information about “ErrorDocument” check out this article.

That should be it! Now when you load your site, your CMS should still rewrite URLs to index.php as expected and you should be able to access sub-directories without issue.

Photo credit: Van Jacobs

Find out more about ServInt solutions

Starting at $25

  • Hosting Advice
  • Computer World
  • Ars Technica

  • The New York Times
  • The Seattle Times
  • Bloomberg
  • The Hill

To engage with the ServInt Sales Team use the following chat icon. Normal sales hours are Monday-Friday 9am-5pm EST but feel free to leave a message and we will follow up as soon as possible.

Sales Chat

To engage with the ServInt Support Team you must be logged into our Customer Portal for identity verification and have a ticket opened about your request or there will only be limited support offered.

Support Chat