This is the product of original research conducted by our company, offering a quite thorough protection
against a plethora of known threats when enabled. This feature is based on the tenet that nothing executes on
files) it makes it extremely hard —but not outright impossible— for an attacker to hack your site, even if he
manages to exploit a security vulnerability to upload malicious PHP code to your site. Additionally, it will
deny direct access to resources not designed to be directly accessible from the web, such as translation files,
which are usually used by attackers to find out which version of WordPress you are running on your site to
tailor an attack to your site. On the downside, you have to explicitly enable access to some plugins' PHP files
which are designed to be called directly from the web and not through WordPress' main file,
Do note that enabling this feature will kill the functionality of some extensions which create arbitrarily named PHP files throughout your site, e.g. in subdirectories of wp-content/plugins. In our humble opinion the security risk of having your site unprotected outweighs the benefits of such solutions.
Before describing what each option does, a small explanation of how the protection works is in order. The
protection code in the generated
.htaccess file blocks direct web access to all files.
WordPress's standard "entry point" or "main" file,
index.php, is automatically exempt from
For each of the back-end and front-end protection we need a set of directories where such files are allowed and
the file extensions of those files. These are what those options are all about. The default settings contain the
most common file types you'd expect to find on a site and the standard WordPress directories where they should
be located. You only have to tweak them if you want to add more file extensions or have such static files in
locations other than the default.
Disables direct access to most resources, except those in the exceptions lists. It is generally recommended to turn it on to enhance the protection of your site.
The extensions of files which allowed to pass through the server protection filter. Place one file extension per line, without the dot. For example, if you want to allow access to all PDF files you have to type in pdf on a new line of this list. Do note that file extensions are case-sensitive. This means that PDF, Pdf, pdf and pDF are four different file extensions as far as your web server is concerned. As a rule of thumb, type in the extensions in lowercase and make sure that the extensions of the files you upload are also in lowercase.
File extensions added here are allowed inside WordPress' default directories (wp-includes and wp-content). Moreover, only files with these extensions are allowed in the directories placed under the “Directories where only files with allowed extensions will be accessible” option (see below).
The following section is Exceptions. This allows specific files or all files in specific directories to
pass through the Server Protection filter without further questions. This is required for several reasons. For
starters, WordPress' core features depend on direct access to files. Some plugins also need to directly access
PHP files, without passing them through WordPress' index.php. One such example is Akeeba Backup Professional's
restore.php used in the integrated restoration feature, as it would be impossible to use
the index.php of a site which is in a state of flux while the restoration is underway. Finally, you may have a
third party script which doesn't install as a WordPress plugin. The Server Protection feature would normally
block access to it and you still need a way around this limitation. So here we have those workarounds:
Place one file per line which should be exempt from filtering, therefore accessible directly from the web. The default settings only include WordPress core files which need to be accessed directly.
You do not need to add anything that is located wp-admin. That folder is always allowed direct access. If you want to best protect your site we recommend that you use the Password Protect wp-admin feature of Admin Tools to apply a server-level password protection to your wp-admin folder. This will very efficiently protect it from hackers.
Place one directory per line. Only files with extensions matching the “File extensions allowed” will be accessible in these directories. Any other file will NOT be allowed to be accessed over the web.
This is useful for folders which have non-executable files such as
Place one directory per line. All files in these directories, except those with a .php extension, will be allowed to be accessed directly from the web. Please note that this option differs from the one above. Directories in this list allow all file extensions, not just the ones listed in “File extensions allowed”. Only files with .php and similar extensions (such as .phps, .php5 and so on) are blocked.
Place one directory per line. This option should be used as sparingly as possible. Each and every directory placed in this list is no longer protected by Server Protection and can be potentially used as an entry point to hacking your site. As far as we know there are only three cases when its use is even marginally justifiable:
If you have installed another WordPress, Joomla!, phpBB, or any other PHP application in a
subdirectory of your site. For example, if you are trying to restore a copy of your site inside a
test in your site's root you have to add
test to this list. This is the one and only usage scenario which doesn't
compromise your site's security.
Some plugins generate .php files with arbitrary file names and expect them to be directly accessible from the web. This is insecure because you cannot tell which files are legitimate and which are suspicious just by looking at their filenames. Hackers understand that and know of these plugins, therefore they will try to hide their hacking scripts inside these folders: it's hiding a tree inside a forest.
Please note that this practice is dangerous. If you want to allow it it's your site and your risk assessment. Just don't come back and wonder why Admin Tools didn't protect you when it's you who has decided to cut a hole in the fence :)
In order to figure out which custom exceptions you need to add on your site, take a look at the How to determine which exceptions are required section.
Windows users beware! Do not use Windows' path separator (the backslash - \) to
separate directories! We are talking about directories as they appear in URLs, so you should always use the
URL path separator (forward slash - /) in those settings. In other words
In the following example we are going to use Google Chrome to detect access issues on a site. Similar tools are built-in in other major browsers, such as Firefox, Opera, Safari, Edge and Internet Explorer 8 or later.
A typical indication that something went wrong is that CSS has gone missing or an action does not complete.
In order to figure out what is going wrong, we have to find out which of the files referenced by the page are throwing a 404 error (this means that they are filtered out by Server Protection), their naming pattern and location. Provided that you are using Chrome open up the Developer Tools pane by typing CTRL-SHIFT-I while viewing that broken page. Click on the Network tab. Reload the page. A list of files the browser tried to access appears.
Go through this list and look for items in red. Look at the Status column. If you have a 404 or 403 you have located the files which probably have the problem.
Click on each red file. The right hand part of the window changes to display some debugging info about that file. Make sure the Headers tab is selected. The interesting part is the request URL which tells you where that file came from.
First, make sure these files really do exist. If they don't exist it's a legitimate 404 (not found)
error and you can't do much about it. It the files do exist they are being blocked by our .htaccess file. Try
adding the file path relative to your site's root (NOT the file URL!) in the Allow direct access to
these files list in the .htaccess Maker. Then save and create
and reload the page.If you repeat the process you'll see that this file now loads correctly.