Table Of Contents

Previous topic

Example Drupal Configuration

Next topic

Client Configuration

This Page

What Goes in to a Document Root and What Does Not Belong There?

Security is a big issue and in this article, we explain how to prevent accidental disclosure of program code and system settings for web applications.

A document root is normally the directory hierarchy that is published on the web. This is to say, that everything in the document root is published, and is therefore considered to be public – unless of course it is locked down by other means, such as password protection.

Imagine for example a public website, running Drupal.

Drupal is one of many web applications that comes in a tarball you extract the contents of, and you typically dump those contents inside the directory hierarchy of a document root. As such, Drupal is a good example to get started with, examining what exactly is put in to the document root (and would therefore be considered “published”), what information is in these files, who has access to them, why this could be considered bad, how to protect the deployment of such an application, and how to develop web applications in such a way that the level of protection on a server-side configuration level may not need to be as complex.

Document Root Content Review (for a Drupal Site)

Imagine, if you will, the document root is /var/www/html/, and you have put Drupal in /var/www/html/drupal-$x.$y/.


We assume a default configuration of one’s webserver, with Apache’s httpd version series 2.4, that comes with certain defaults such as AllowOverride None, preventing any .htaccess file from modifying access levels and other settings.

What you intend to publish may be limited to:

  • drupal-$x.$y/favicon.ico
  • drupal-$x.$y/index.php
  • drupal-$x.$y/misc/*.css
  • drupal-$x.$y/misc/*.gif
  • drupal-$x.$y/misc/*.ico
  • drupal-$x.$y/misc/*.js
  • drupal-$x.$y/misc/*.png
  • drupal-$x.$y/misc/farbtastic/
  • drupal-$x.$y/misc/ui/
  • drupal-$x.$y/modules/ (assets only)
  • drupal-$x.$y/xmlrpc.php
  • drupal-$x.$y/themes/garland/*.css
  • drupal-$x.$y/themes/garland/color/*.css
  • drupal-$x.$y/themes/garland/color/*.png
  • drupal-$x.$y/sites/all/modules/ (assets only)
  • drupal-$x.$y/sites/default/files/
  • drupal-$x.$y/sites/default/modules/ (assets only)

But what is actually considered “published” – since it is in the document root, includes (among others), the following files:


Part of the Drupal core modules, these files contain the exact version number of Drupal modules, usually the same version number as the Drupal core.

Should an attack vector exist against a particular Drupal version, which is not an uncommon occurence, then disclosing the version number aids attackers in narrowing their attempts to include only the ones the attacker considers valid.



Contain the program logic of a module, and would be served in plain- text unless access is specifically prevented.


name = OpenID
description = "Allows users to log into your site using OpenID."
version = VERSION
package = Core
core = 7.x
files[] = openid.test

; Information added by packaging script on 2014-11-19
version = "7.34"
project = "drupal"
datestamp = "1416429488"

In addition to the aforementioned files that are usually part of stock versions of Drupal core, modules and themes, most of which are likely publicly available elsewhere (not on your site), you may also load custom modules and themes, and/or patch certain aspects of the stock versions to make something work for your deployment. You will have even less desire to unintentionally publish this custom code.

Furthermore, at a lower risk of disclosure but with a greater risk of compromising the site if not the server, Drupal by default retains the site’s settings inside the document root – at /var/www/html/drupal-$x.$y/sites/default/settings.php in our example.

This .php file is normally handled by the PHP module loaded in to the webserver, but if it is not – through genuine misconfiguration of the web server software – your database address, name and access credentials would be out in the open. Even if the database is not publicly accessible, the site administrator may have been configured with the same passphrase, and the settings disclose the database technology used – such that the use of SQLite could be exploited in a DoS attack.

How to Protect a Document Root?

Under the working assumption that everything in a document root is published, and with Apache’s httpd 2.4 defaults including AllowOverride None, your means of protection are limited to server-side configuration, most commonly limited to privileged system accounts (such as the root user).


Some web hosting technologies allow you to specify and tweak certain aspects of the web server configuration through an Include or an IncludeOptional statement that includes configuration from a location where you can write, and/or negate a default of AllowOverride None by specifying which aspects may be configured in a .htaccess file.

A common approach to preventing access to a set of files of which the exact name, path or location is unknown, or under circumstances where such list of files is dynamic, is to block everything by default and create a whilelist for content that is to be published, rather than block access to each known file individually.

An example whitelist configuration for a Drupal installation could look as follows in the Example Drupal Configuration.

Kolab Groupware Software Components and DocumentRoots