Hiding information from visitors

If someone is attacking your site and is able to determine information about which version of Drupal or which specific modules or themes you are using it might make it easier for them to exploit a vulnerability.

This is not an important issue. There are other ways in which an attacker could determine information about your site. However, it's also a good practice to give a potential attacker as little information as possible. If you are one of the paranoid people who already keeps your site up to date and follows all the best practices listed in this section then the rest of this page may be interesting to you.

Directory Index Potential Problem

By default Drupal core ships with a directive in the .htaccess file which will give a "Forbidden" message if a user attempts to view a directory. For example, if you visit the sites/all/modules directory on drupal.org you should get a "Forbidden" 403 error message. This helps protect your site because people will not be able to probe your site for information about which modules you are using. If your web server does not allow configuration via the .htaccess file then this protection may not be in place. A good way to figure out if the .htaccess rule is working is to visit your sites directory (e.g. http://example.com/sites/ ) and see if you get a listing of files or just a "Forbidden" message.

Possible Solutions To the Directory Index Problem

You could alter your webserver's configuration so that this information is hidden - either on a server wide basis or just for your Drupal installation.

If you do not have access to the configuration files, you could also simply place an empty file named "index.php" or "index.html" into each directory on your site. If done properly then visitors to your site will see a blank page instead of the directory contents.

Error Log - Write Errors to a log, not the screen

Drupal gives the admin the option to write errors to the log or to the log and to the screen. During development it is useful to write errors to the screen so you can see all the misconfigurations in modules or mistakes in code. However, on a live site this information can be used by an attacker to more quickly break into your site.

The solution for production sites is to only log the errors to the database/log file and not to the screen:

You can reach this page by browsing to Administer > Site configuration > Error reporting.

CHANGELOG.txt, README.txt and others

There are many files in an installation such as CHANGELOG.txt and README.txt which may include version information. You could delete those files but they often contain useful information. A better solution is to simply move those files outside of the web accessible area of your installation or to simply rename them.

Again, it's more important to review other aspects of Secure Configuration of your site rather than worry about this information disclosure.