The .htaccess maker


This feature is only available in the Professional release


This feature is only available on servers running the Apache web server. If your server is using IIS or NginX the button to launch this feature will not be shown. If you are using Lighttpd, Litespeed or any other server software you will see a button to launch this feature but this feature may not have any effect. If unsure please consult with your host about their server's support of .htaccess files.

One of the most important aspects of managing a web site hosted on an Apache server is being able to fine-tune your .htaccess file. This file is responsible for many web server level tweaks, such as enabling the use of search engine friendly (SEF) URLs, blocking access to system files which should not be accessible from the web, redirecting between pages based on custom criteria and even optimising the performance of your site. On the downside, learning how to tweak all those settings is akin to learning a foreign language. The .htaccess Maker feature in Admin Tools helps you create such a file with a user-friendly interface.


Some prepackaged server bundles and some live hosts do not allow using .htaccess files to override server settings. If it is a local server, edit your httpd.conf file and modify every AllowOverride line to read:

AllowOverride All

If you are on a live host, please consult your host about the possibility of them allowing you to use this feature on your site.


If you ever want to revert to a "safe default", just set all of the options on this page to "Off" and click on "Save and create .htaccess". This will create a very basic .htaccess file which is essentially the same as the one shipped with Joomla! (htaccess.txt) without any of the optional sections.

The top part of the .htaccess maker page contains the standard toolbar buttons you'd expect:

The .htaccess Maker's toolbar

  • Save and create .htaccess saves the changes you have made in this page's options and creates the new .htaccess file. If you already had a .htaccess file on your site, it will be renamed to .htaccess.admintools before the new file is written to disk.

  • Save without creating .htaccess (visible after clicking the dropdown arrow next to the previous button) saves the changes you have made in this page's options without creating a new .htaccess file. This should be used when you have not decided on some options yet, or if you want to preview the generated .htaccess file before writing it to disk.

  • Reset Htaccess Maker options will reset all options on the page to the default settings you'd see when first installing Admin Tools. Please note that this is NOT the same as turning off every option! The default settings have several features turned on. Use this button only when you feel you've messed up so bad you don't even know where to begin fixing things.

  • Preview pops up a dialog where you can see how the generated .htaccess file will look like without writing it to disk. This dialog shows the saved configuration. If you have modified any settings they will not be reflected in there until you click either of the save buttons.

  • The Back button takes you back to the Control Panel page.

Below the toolbar there are five panes with different options, described below. Before you do that, please read and understand the following warning. Support requests which indicate that you have not read it will be replied with a link back to this page.

Please bear in mind that depending on your web server settings, some of these options may be incompatible with your site. In this case you will get a blank page or an Internal Server Error 500 error page when trying to access any part of your site. If this happens, you have to remove the .htaccess file from your site's root directory using an FTP application or the File Manager feature of your hosting control panel. Your old .htaccess file is saved as .htaccess.admintools. You can rename that file back to .htaccess to revert to the last known good state. If you are unsure how this works, please consult your host before trying to create a new .htaccess file using this tool.

Some prepackaged server environments, like WAMPserver, do not enable Apache's mod_rewrite module by default, which will always result in an Internal Server Error upon applying the .htaccess file. In this case you are strongly suggested to enable it. On WAMPserver you can click on its tray icon, go to Apache, Modules and make sure rewrite_module is checked. On other server environments you have to edit your httpd.conf file and make sure that the LoadModule mod_rewrite line is not commented out (there is no hash sign in front of it). Once you do either of these changes, you must restart your server for the change to become effective.

If this is the first time you are using the .htaccess Maker we recommend that you begin by setting all options to No and then enable them one by one, creating a new .htaccess file after you have enabled each one of them. If you bump into a blank or error page you will know that the last option you tried is incompatible with your host. In that case, remove the .htaccess file, set the option to No and continue with the next one. Unfortunately, there is no other way than trial and error to deduce which options may be incompatible with your server.

Other important things you can add to your .htaccess

Some things cannot be added as features to the .htaccess Maker because the interface would become truly unwieldy. However, there are tools which can generate rather compact .htaccess rules which you can add to .htaccess Maker, in the Custom .htaccess rules at the top of the file section. Here we'd like to point you to some of them.

Content security policy (CSP)

It mitigates the risk of cross-site scripting and other content-injection attacks. Joomla 4 includes a component which can do that for you. The downside is that the component's options only apply to the pages generated by Joomla 4 itself.

Alternatively, you can read more about it on the dedicated site for this feature. There is a simple tool which allows you to generate the required .htaccess code for the CSP feature according to your preferences. Keep in mind that when you restrict the scripts' origin you should keep in mind that several extensions (including many templates) will load their scripts off a third party CDN which must be explicitly allowed or your site will no longer work!

Custom error documents

Most hosting control panels allow you to specify custom HTML pages for common server error pages. The most important ones are for errors 403 (Access Forbidden), 404 (Not Found) and 500 (Internal Server Error). It's always a good idea showing a nicely designed page instead of the default, text-only, ugly page of Apache for these error messages!

Beware of your hosting folder structure

If you have created subdomains please make sure that their web root is outside of the web root of your main site.

For example, this directory layout is CORRECT:

<your account folder>
   +-- public_html    (Main site's web root)
   +-- foobar_html    (Subdomain's web root - CORRECT)

Whereas this directory layout is WRONG:

<your account folder>
    +-- public_html        (Main site's web root)
          +-- foobar_html  (Subdomain's web root - WRONG)

The reason is explained in Apache's official documentation and has to do with the way the .htaccess directives cascade across filesystem directories, not configured domains / subdomains:


The configuration directives found in a .htaccess file are applied to the directory in which the .htaccess file is found, and to all subdirectories thereof. However, it is important to also remember that there may have been .htaccess files in directories higher up. Directives are applied in the order that they are found. Therefore, a .htaccess file in a particular directory may override directives found in .htaccess files found higher up in the directory tree. And those, in turn, may have overridden directives found yet higher up, or in the main server configuration file itself.

 --Apache Official Documentation

If you end up with a subdomain's web root under the main site's web root the .htaccess file of the main site will also be used in the subdomain. Even if you create a different .htaccess file in the subdomain, the way Apache applies the parent directory's .htaccess directives will get in the way. You will have several problems which will make your site appear broken, files inaccessible etc.

Basic Security

Basic security

Disable directory listings (recommended)

When disabled, your web server might list the files and subdirectories of any directory on your site if there is no index.html file inside it. This can pose a security risk, so you should always enable this option to avoid this from happening.

Protect against common file injection attacks

Many attackers try to exploit vulnerable extensions on your site by tricking them into including malicious code hosted on the attacker's server. Enabling this option will protect your server against this kind of attacks. This works by preventing any URL which references an http:// or https:// URL in the query string. Sometimes these are legitimate requests. For example, some gallery components use them. In this case you are recommended to use the RFIShield (Remote File Inclusion protection) in the Web Application Firewall and turn this .htaccess Maker option OFF.

Block access to configuration.php-dist and htaccess.txt

These two files are left behind after any Joomla! installation or upgrade and can be directly accessed from the web. They are used by attackers to tell the Joomla! version you are using, so that they can tailor an attack targeting your specific Joomla! version. Enabling this option will "hide" those files when accessed from the web (a 404 Not Found page is returned), tricking attackers into believing that these files do not exist and making it slightly more difficult for them to deduce information about your site. This option also hides the web.config.txt file included in Joomla! 3 and later for use with the IIS server.

Protect against clickjacking

Turning on this option will protect you against clickjacking. It does so by preventing your site's pages to be loaded in a, Frame, IFrame or Object tag unless this comes from a page inside your own site. Please note that if your site relies on its pages being accessible through frames / iframes displayed on other sites (NOT on your site displaying content from other sites, that's irrelevant!) then you should not enable this option. If unsure, enable it.

Reduce MIME type security risks

Internet Explorer 9 and later, as well as Google Chrome, will try by default to guess the content type of downloaded documents regardless of what the MIME header sent by the server. Let's say a malicious user to upload an executable file, e.g. a .EXE file or a Chrome Extension, under an innocent file extension as .jpg (image file). When a victim tries downloading this file, IE and Chrome will try to guess the file type, identify it as an executable file and under certain circumstances executing it. This means that your site could be unwittingly used to serve malware. Such an event could result in your site being added to a list of known bad sites by browser makers and cause their browsers to display a warning to users when visiting your site. By enabling this feature you instruct IE and Chrome to respect the file type sent by your server, eliminating this issue. See the relevant MSDN article for more information.

Reflected XSS prevention

When enabled the browser will be instructed to prevent reflected XSS attacks. Reflected XSS attacks occur when the victim is manipulated into visiting a specially crafted URL which contains Javascript code in it. This URL leads to a vulnerable page which outputs this Javascript code verbatim in the page output ("reflects" the malicious code sent in the URL).

This is a commonly used method used by attackers to compromise web sites, especially when a zero-day XSS vulnerability is discovered in popular Joomla! extensions or Joomla! itself. The attacker will try to trick the administrators of websites into visiting a maliciously crafted link. If the victims are logged in to their site at that time the malicious Javascript will execute, typically giving the attacker privileged information or opening a back door to compromising the site.

Enabling this option in .htaccess Maker will instruct the browser to try preventing this issue. Please note that this only works on compatible browsers (IE8; Chrome; Safari and other WebKit browsers) and only applies to reflected XSS attacks. Stored XSS attacks, where the malicious Javscript is stored in the database, is NOT prevented. You should consider this protection a safety belt. Not wearing a safety belt in the event of an accident pretty much guarantees serious injury or death. Wearing a safety belt minimises the possibility of injury or death but does not always prevent it. This option is your safety belt against the most common type of XSS attacks. You should use it but don't expect it to stop everything thrown your way. Always keep your software up-to-date, especially when a security release is published!

For more information please consult the relevant MSDN article.

Neutralise SVG script execution

Send a custom Content Security Policy HTTP header for SVG files which prevents scripts inside them from executing. Doing so will also disable most SVG animations and remove all interactive features from all SVG files.

This option only needs to be enabled if your site is configured in such a way that it allows untrusted users to upload unsanitized SVG files to your site. By default, Joomla does NOT permit this. You'd have to configure it to do so yourself, using the Media Manager's options page and / or a third party extension.

Note that unlike the Site Protection features, this will apply to all SVG files regardless of their location.

Remove web server and PHP version signature

By default Apache and PHP will output HTTP headers advertising their existence and their version numbers. If you are always using the latest and greatest versions this may not be a problem, but the chances are that your host is using an older version of both software. Giving away the version numbers of the server software in every request makes it trivial for an attacker to obtain information about your site which will help them to launch a tailored attack, targeting known security issues in the versions of Apache and PHP you're using. Enabling this option will mitigate this issue. Please note that this is SECURITY THROUGH OBSCURITY which is NEVER, EVER an adequate means of protection. It's just a speed bump in the way of an attacker, not a roadblock.

You are strongly advised to keep your server software up-to-date. If you're not managing your own server, e.g. you're using a shared host, we very strongly recommend choosing a hosting service which follows this rule. As a simple test, if your server is not currently using one of the PHP versions published in the top right corner of (or at most one version earlier, i.e. the third number of the version on your server is one less than the one listed on the chances are that your server is using outdated, vulnerable server software. Remember that outdated versions of PHP and Apache, even with some security patches backported, CAN NOT be secure. There's a good reason new software versions are published regularly.

Prevent content transformation

Enabling this feature instructs proxy servers and caches to not convert your content. For example, certain proxy servers (typically found in mobile networks, businesses and ISPs in congested areas) will attempt to scale and aggressively compress images, CSS and Javascript to save bandwidth. This can lead to several issues, from displayed images being a bit off to your site breaking down because the compressed CSS/JS introduced errors preventing the browser from parsing it correctly. With this feature enabled the cache and proxy servers will be instructed to not do that by setting an HTTP header. If they respect the HTTP header (they should, it's a web standard) such issues are prevented.

For more information please consult the formal web standard document RFC 2616, section 14.9.5

Block access from specific user agents

When enabled, it will block any site access attempt if the remote program sends one of the user agent strings in the User agents to block option. This feature is designed to protect your site against common bandwidth-hogging download bots and otherwise legitimate tools which are more usually used for hacking sites than their benign intended functionality.

User agents to block

The user agent strings to block from accessing your site. You don't have to enter the whole UA string, just a part of it. The default setting includes several usual suspects.

You can type new entries by clicking at the end of the list, type the entry and press ENTER to accept it. Delete items using the X button next to each entry.

Do note that some server with mod_security or mod_evasive installed will throw an "Access forbidden" message if you try to save the configuration settings when this field contains the word "WGet". If you come across this issue it is not a bug with Admin Tools or Joomla!, it is a server-level protection feature kicking in. Just avoid including the word Wget and you should be out of harm's way.

Default list of user agents to block

The following is the default list of user agents to block. It is very thorough and seems to be reducing the number of attacks enormously. If you are upgrading from an earlier version you might want to try it out.

Bolt 0
Bot mailto:[email protected]
Default Browser 0
Download Demon
Express WebPictures
Image Stripper
Image Sucker
Internet Ninja
JOC Web Spider
Mass Downloader
MIDown tool
Mister PiX
Net Vampire
Offline Explorer
Offline Navigator
Papa Foto
Rippers 0
Teleport Pro
Toata dragostea mea pentru diavola
Web Image Collector
Web Sucker
WebGo IS
Website eXtractor
Website Quester
Xaldon WebSpider
Indy Library
ISC Systems iRc Search 2.1
Microsoft URL Control
Missigua Locator
Web Sucker
Wells Search II
WEP Search
Indy Library