Improve Security by Protecting .htaccess

♦ Posted by Jeff Starr in .htaccess, Security

Updated July 4, 2018 • 25 comments

As you know, HTAccess files are powerful tools for manipulating site performance and functionality. Protecting your site’s HTAccess files is critical to maintaining a secure environment. Fortunately, preventing access to your HTAccess files is very easy. Let’s have a look..

Different Methods

If you search around the Web, you will probably find several different methods of protecting your HTAccess files. Here are a few examples, along with a bit of analysis and discussion.

Case-sensitive protection

As far as I know, this is the most widespread method of protecting HTAccess files. Very straightforward, this code will prevent anyone from accessing any file named precisely “.htaccess”. This is not ideal because the match is case sensitive. On certain systems, HTAccess files protected with this method may remain accessible via “HTACCESS”, for example.

# CASE SENSITIVE METHOD
<Files .htaccess>
	Order allow,deny
	Deny from all
</Files>

Weak pattern matching

Recently, I have been seeing several instances of this particular technique. Using the same general strategy, this method will prevent access to any file beginning with the characters “.ht”. The assumption here is that HTAccess files are the only files that begin with “.ht”. Thus, by simply matching these first three characters, all HTAccess files — and only HTAccess files — will be protected from external access. Unsafe assumptions aside, this method also relies on a case-sensitive match in order to work. Note, however, the addition of the “Satisfy All” directive in the penultimate line — this is an improvement over the previous method.

# WEAK PATTERN MATCHING
<Files ~ "^\.ht">
	Order allow,deny
	Deny from all
	Satisfy All
</Files>

Strong pattern matching

This is the method that I use here at Perishable Press. Using strong pattern matching, this technique prevents external access to any file containing “.hta”, “.HTA”, or any case-insensitive combination thereof. To illustrate, this code will prevent access through any of the following requests:

.htaccess
.HTACCESS
.hTaCcEsS
testFILE.htaccess
filename.HTACCESS
FILEROOT.hTaCcEsS

..etc., etc. Clearly, this method is highly effective at securing your site’s HTAccess files. Further, this technique also includes the fortifying “Satisfy All” directive. Note that this code should be placed in your domain’s root HTAccess file:

# STRONG HTACCESS PROTECTION
<Files ~ "^.*\.([Hh][Tt][Aa])">
	Order allow,deny
	Deny from all
	Satisfy all
</Files>

Suggestionz

Can you improve on this technique? How do you protect your HTAccess files? Speak up!

apache tips

About the Author

Jeff Starr = Web Developer. Security Specialist. WordPress Buff.

25 responses to “Improve Security by Protecting .htaccess”

Sat 2008/05/20 7:35 pm

I can see how your version is superior and thanks for sharing, but don’t understand the need for “satisfy all”. According to both apache 1.3 and 2.0 docs, satisy all/any is only useful when combined with “require”, i.e.satisy user auth and deny/permit.You are far more knowledgable with .htaccess and apache than I am, so was just wondering if there is anything I’m missing with this because I didn’t see a require directive here.

Perishable 2008/05/20 9:13 pm • Post Author

Yes, you are correct. I should have verified my sources before posting this article. Although I don’t think inclusion of the “satisfy all” directive does any particular harm when used in this context, it certainly isn’t “fortifying” anything either.

Thanks for keeping me honest, Sat! ;)

Louis 2008/05/21 6:30 am

Hey, I though the .htaccess were by default protected from external queries !

I wonder if it wouldn’t be easier (and less ressources eating) to CHMOD the .htaccess so that it can only be read by the server.

Perishable 2008/05/21 4:28 pm • Post Author

The idea here is to protect your htaccess files on multiple fronts. Yes, on properly configured servers, htaccess files should be restricted by default, however, if someone discovers an associated vulnerability, and no additional security measures are in place, serious damage could be done. As you mention, setting an appropriate CHMOD value for htaccess files is also important, as it provides a secondary measure of protection, however, even then, if someone discovers a way around this, extensive damage could be done. Granted, these cases are merely hypothetical, however because of the inherent power involved with htaccess directives, it is important to secure htaccess files on as many levels as possible. The protective technique(s) provided in this article provide a tertiary level of defense on properly configured machines.

Bottom line: it never hurts to have too much protection when it comes to htaccess. If a fourth method were available, I would use it as well.

Aldo 2008/08/22 2:52 am

Thank you very much for your blog: it was (and is) very very useful to me.

About CHMOD of htaccess, can I know what’s the best value? 644?

Jeff Starr 2008/09/01 9:54 am • Post Author

Hi Aldo, Thanks for the kind words :)

As for CHMOD values, it’s always best to use the most secure settings possible. That is, if you can get away with using 644 and still maintain the desired functionality, then use it. If that is too restrictive, then try the next least permissive setting (e.g., 755), and so on. Only as a last reort (and in some cases not at all) should you enable full rights (e.g., 777) for any file or folder. Unfortunately, in many cases, that is the only thing that will work.

Aldo 2008/09/01 11:02 am

Yep, I am using 644!
Thanks for your kind reply. ;)

Alex 2008/12/26 10:36 am

It is even safer to use 444 CHMOD code rather than 644.

Jeff Starr 2009/01/01 10:56 am • Post Author

@Alex: indeed, that is the case if the file/folder retains its functionality with such restrictive settings applied. In my experience, some server configurations are rather picky when it comes to file permissions. My rule of thumb is to always go with the most secure settings possible, but unfortunately on my current server, 644 is about as restrictive as I can go without sacrificing functionality.

jidanni 2009/02/19 9:03 pm

First of all, all the servers I’ve encountered don’t let people browse .htaccess.

Second, I don’t see how any 444 (-r–r–r–) permission or looser is considered secure in terms of not letting somebody read something.

If you want something wacky, see https://core.trac.wordpress.org/ticket/9185 where people can execute PHP left and right.

Tom Lewis 2009/04/04 7:31 am

Oh, wow, thats ausom, i didnt realize that you could read other peoples .htaccess files!

Thanks for the heads up!

Jeff Starr 2009/04/06 12:24 pm • Post Author

@Tom Lewis: Actually you can’t. At least not theoretically. When Apache is installed and configured correctly with the proper modules and security settings implemented, external access to per-directory HTAccess files is explicitly prohibited.

Of course, when these conditions aren’t met, or if there is a conflict with a third-party script, Frontpage extensions, or even other HTAccess directives, the protective measures for HTAccess files may not function as expected.

Such situations are hopefully rare, but the information provided in this post should cover your bases and keep your site secure should such a vulnerability present itself.

Better safe than sorry!

Comments are closed for this post. Something to add? Let me know.

Sat 2008/05/20 7:35 pm

I can see how your version is superior and thanks for sharing, but don’t understand the need for “satisfy all”. According to both apache 1.3 and 2.0 docs, satisy all/any is only useful when combined with “require”, i.e.satisy user auth and deny/permit.You are far more knowledgable with .htaccess and apache than I am, so was just wondering if there is anything I’m missing with this because I didn’t see a require directive here.
Perishable 2008/05/20 9:13 pm • Post Author

Yes, you are correct. I should have verified my sources before posting this article. Although I don’t think inclusion of the “satisfy all” directive does any particular harm when used in this context, it certainly isn’t “fortifying” anything either.

Thanks for keeping me honest, Sat! ;)
Louis 2008/05/21 6:30 am

Hey, I though the .htaccess were by default protected from external queries !

I wonder if it wouldn’t be easier (and less ressources eating) to CHMOD the .htaccess so that it can only be read by the server.
Perishable 2008/05/21 4:28 pm • Post Author

The idea here is to protect your htaccess files on multiple fronts. Yes, on properly configured servers, htaccess files should be restricted by default, however, if someone discovers an associated vulnerability, and no additional security measures are in place, serious damage could be done. As you mention, setting an appropriate CHMOD value for htaccess files is also important, as it provides a secondary measure of protection, however, even then, if someone discovers a way around this, extensive damage could be done. Granted, these cases are merely hypothetical, however because of the inherent power involved with htaccess directives, it is important to secure htaccess files on as many levels as possible. The protective technique(s) provided in this article provide a tertiary level of defense on properly configured machines.

Bottom line: it never hurts to have too much protection when it comes to htaccess. If a fourth method were available, I would use it as well.
Aldo 2008/08/22 2:52 am

Thank you very much for your blog: it was (and is) very very useful to me.

About CHMOD of htaccess, can I know what’s the best value? 644?
Jeff Starr 2008/09/01 9:54 am • Post Author

Hi Aldo, Thanks for the kind words :)

As for CHMOD values, it’s always best to use the most secure settings possible. That is, if you can get away with using 644 and still maintain the desired functionality, then use it. If that is too restrictive, then try the next least permissive setting (e.g., 755), and so on. Only as a last reort (and in some cases not at all) should you enable full rights (e.g., 777) for any file or folder. Unfortunately, in many cases, that is the only thing that will work.
Aldo 2008/09/01 11:02 am

Yep, I am using 644!
Thanks for your kind reply. ;)
Alex 2008/12/26 10:36 am

It is even safer to use 444 CHMOD code rather than 644.
Jeff Starr 2009/01/01 10:56 am • Post Author

@Alex: indeed, that is the case if the file/folder retains its functionality with such restrictive settings applied. In my experience, some server configurations are rather picky when it comes to file permissions. My rule of thumb is to always go with the most secure settings possible, but unfortunately on my current server, 644 is about as restrictive as I can go without sacrificing functionality.
jidanni 2009/02/19 9:03 pm

First of all, all the servers I’ve encountered don’t let people browse .htaccess.

Second, I don’t see how any 444 (-r–r–r–) permission or looser is considered secure in terms of not letting somebody read something.

If you want something wacky, see https://core.trac.wordpress.org/ticket/9185 where people can execute PHP left and right.
Tom Lewis 2009/04/04 7:31 am

Oh, wow, thats ausom, i didnt realize that you could read other peoples .htaccess files!

Thanks for the heads up!
Jeff Starr 2009/04/06 12:24 pm • Post Author

@Tom Lewis: Actually you can’t. At least not theoretically. When Apache is installed and configured correctly with the proper modules and security settings implemented, external access to per-directory HTAccess files is explicitly prohibited.

Of course, when these conditions aren’t met, or if there is a conflict with a third-party script, Frontpage extensions, or even other HTAccess directives, the protective measures for HTAccess files may not function as expected.

Such situations are hopefully rare, but the information provided in this post should cover your bases and keep your site secure should such a vulnerability present itself.

Better safe than sorry!

12 • Newer Comments »